Should $.map() also work for objects?

[gMinuses]

I'm not sure if it's necessary, but I feel It'd be nice that we can
pass an object to $.map(), so that jquery will iterate over it's
properties and modifies values by calling the callback function:

var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
$.map( obj, function( value, key ) {
    return function() {
        // Call old function
        value();

        // Do something else;
    };
})

If the idea is redundant because of my lack of knowledge, please let
me know how to do it natively, thanks. ( If you are going to suggest "
for( in ) ", I think it doesn't have the benefit of scoping )

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

On Thu, Oct 29, 2009 at 4:56 AM, gMinuses <gminuses@...> wrote:
> I'm not sure if it's necessary, but I feel It'd be nice that we can
> pass an object to $.map(), so that jquery will iterate over it's
> properties and modifies values by calling the callback function:

I think that would be quite different from the way map currently
works, which does not modify the array passed in but returns a new
array whose values are the results of applying the callback function
to each successive value of the original one.

> var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
> $.map( obj, function( value, key ) {
>    return function() {
>        // Call old function
>        value();
>
>        // Do something else;
>    };
> })

I'm not making much sense out of that.  Are you assuming that every
property of the "obj" parameter is a function?  Can you give some
context and a more real-world example?  This does not sound hard to
write, but I'm not seeing the benefits.


> If the idea is redundant because of my lack of knowledge, please let
> me know how to do it natively, thanks. ( If you are going to suggest "
> for( in ) ", I think it doesn't have the benefit of scoping )

I don't know what scoping issue you're talking about, but I think that
the only real way to enumerate the properties of an object involves
for-in.

  -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Robert Katić]

Be warned that $.map() is designed to work on a sequence of DOM
elements. Although it would work with other values too, callback
results are not handled as you probably expect: null and undefined
values are discarded and arrays are merged to the final array.

In your case an classic for(key in obj) would be more appropriate, I
think.

On Oct 29, 9:56 am, gMinuses <gminu...@...> wrote:

> I'm not sure if it's necessary, but I feel It'd be nice that we can
> pass an object to $.map(), so that jquery will iterate over it's
> properties and modifies values by calling the callback function:
>
> var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
> $.map( obj, function( value, key ) {
>     return function() {
>         // Call old function
>         value();
>
>         // Do something else;
>     };
>
> })
>
> If the idea is redundant because of my lack of knowledge, please let
> me know how to do it natively, thanks. ( If you are going to suggest "
> for( in ) ", I think it doesn't have the benefit of scoping )

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Robert Katić]

Be warned that $.map() is designed to work on a sequence of DOM
elements. Although it would work with other values too, callback
results are not handled as you probably expect: null and undefined
values are discarded and arrays are merged to the final array.

In your case an classic for(key in obj) would be more appropriate, I
think.

On Oct 29, 9:56 am, gMinuses <gminu...@...> wrote:

> I'm not sure if it's necessary, but I feel It'd be nice that we can
> pass an object to $.map(), so that jquery will iterate over it's
> properties and modifies values by calling the callback function:
>
> var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
> $.map( obj, function( value, key ) {
>     return function() {
>         // Call old function
>         value();
>
>         // Do something else;
>     };
>
> })
>
> If the idea is redundant because of my lack of knowledge, please let
> me know how to do it natively, thanks. ( If you are going to suggest "
> for( in ) ", I think it doesn't have the benefit of scoping )

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

> I think that would be quite different from the way map currently
> works, which does not modify the array passed in but returns a new
> array whose values are the results of applying the callback function
> to each successive value of the original one.

Maybe jQuery could first clone the object:

var newObj = $.extend( {}, obj );
( It's just for the purpose of demonstration, it might have an issue
of efficiency )

> I'm not making much sense out of that.  Are you assuming that every
> property of the "obj" parameter is a function?  Can you give some
> context and a more real-world example?  This does not sound hard to
> write, but I'm not seeing the benefits.

One scenario is that it will be useful, if we want to modify options a
user passed in, which is normally an object and have callbacks in it.

> I don't know what scoping issue you're talking about, but I think that
> the only real way to enumerate the properties of an object involves
> for-in.

This is what I meant:

Let's say this is the options a user passed in:
var options = {
    key: 'value',
    callback1: function() {}
    callback2: function() {}
}

And we want to modify the callback:
( This snippet won't work )

for( key in options ) {
    var option = options[ key ]
    if( $.isFunction( option ) )
        options[ key ] = function() {
            // Call old callback
            option();

            // Do something else
        }
}

It won't work because the "option" here is not scoped, so all modified
callbacks will call whatever callback that is the last one being
iterated.

And it should be written like this:

for( key in options ) {
    // Scope them
    (function() {
        var option = options[ key ]
        if( $.isFunction( option ) )
            options[ key ] = function() {
                // Call old callback
                option();

                // Do something else
            }

    })();
}

If $.map() is able to iterate over objects, it won't have the issue of
scoping:

$.map( options, function( option ) {
    // No need to scope, because it already does
    if( $.isFunction( option ) )
        return function() {
            // Call old callback
            option();

            // Do something else
        }
})

I feel it's a lot neater.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

From it's name, I think It should be general, and should be working on
all kinds of arrays. The object I'm talking about here is actually a
hash, which is a kind of array, and I figure it'd be appropriate to
let $.map() also work for it.

On Oct 30, 3:20 am, Robert Katić <robert.ka...@...> wrote:

> Be warned that $.map() is designed to work on a sequence of DOM
> elements. Although it would work with other values too, callback
> results are not handled as you probably expect: null and undefined
> values are discarded and arrays are merged to the final array.
>
> In your case an classic for(key in obj) would be more appropriate, I
> think.
>
> On Oct 29, 9:56 am, gMinuses <gminu...@...> wrote:
>
> > I'm not sure if it's necessary, but I feel It'd be nice that we can
> > pass an object to $.map(), so that jquery will iterate over it's
> > properties and modifies values by calling the callback function:
>
> > var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
> > $.map( obj, function( value, key ) {
> >     return function() {
> >         // Call old function
> >         value();
>
> >         // Do something else;
> >     };
>
> > })
>
> > If the idea is redundant because of my lack of knowledge, please let
> > me know how to do it natively, thanks. ( If you are going to suggest "
> > for( in ) ", I think it doesn't have the benefit of scoping )

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Robert Katić]

Generally map() functions work on sequences (values indexed by
numbers).

On Oct 30, 1:08 am, gMinuses <gminu...@...> wrote:

> From it's name, I think It should be general, and should be working on
> all kinds of arrays. The object I'm talking about here is actually a
> hash, which is a kind of array, and I figure it'd be appropriate to
> let $.map() also work for it.
>
> On Oct 30, 3:20 am, Robert Katić <robert.ka...@...> wrote:
>
> > Be warned that $.map() is designed to work on a sequence of DOM
> > elements. Although it would work with other values too, callback
> > results are not handled as you probably expect: null and undefined
> > values are discarded and arrays are merged to the final array.
>
> > In your case an classic for(key in obj) would be more appropriate, I
> > think.
>
> > On Oct 29, 9:56 am, gMinuses <gminu...@...> wrote:
>
> > > I'm not sure if it's necessary, but I feel It'd be nice that we can
> > > pass an object to $.map(), so that jquery will iterate over it's
> > > properties and modifies values by calling the callback function:
>
> > > var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
> > > $.map( obj, function( value, key ) {
> > >     return function() {
> > >         // Call old function
> > >         value();
>
> > >         // Do something else;
> > >     };
>
> > > })
>
> > > If the idea is redundant because of my lack of knowledge, please let
> > > me know how to do it natively, thanks. ( If you are going to suggest "
> > > for( in ) ", I think it doesn't have the benefit of scoping )

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

But making map() functions work on hashes makes sense, so why rule
them out?

On Oct 30, 10:08 am, Robert Katić <robert.ka...@...> wrote:

> Generally map() functions work on sequences (values indexed by
> numbers).
>
> On Oct 30, 1:08 am, gMinuses <gminu...@...> wrote:
>
> > From it's name, I think It should be general, and should be working on
> > all kinds of arrays. The object I'm talking about here is actually a
> > hash, which is a kind of array, and I figure it'd be appropriate to
> > let $.map() also work for it.
>
> > On Oct 30, 3:20 am, Robert Katić <robert.ka...@...> wrote:
>
> > > Be warned that $.map() is designed to work on a sequence of DOM
> > > elements. Although it would work with other values too, callback
> > > results are not handled as you probably expect: null and undefined
> > > values are discarded and arrays are merged to the final array.
>
> > > In your case an classic for(key in obj) would be more appropriate, I
> > > think.
>
> > > On Oct 29, 9:56 am, gMinuses <gminu...@...> wrote:
>
> > > > I'm not sure if it's necessary, but I feel It'd be nice that we can
> > > > pass an object to $.map(), so that jquery will iterate over it's
> > > > properties and modifies values by calling the callback function:
>
> > > > var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
> > > > $.map( obj, function( value, key ) {
> > > >     return function() {
> > > >         // Call old function
> > > >         value();
>
> > > >         // Do something else;
> > > >     };
>
> > > > })
>
> > > > If the idea is redundant because of my lack of knowledge, please let
> > > > me know how to do it natively, thanks. ( If you are going to suggest "
> > > > for( in ) ", I think it doesn't have the benefit of scoping )

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

On Oct 29, 11:19 pm, gMinuses <gminu...@...> wrote:
> But making map() functions work on hashes makes sense, so why rule
> them out?

I'm not convinced.  Is this the sort of usage, you are considering?:

    var newMap = function(obj, fn) {
        var options = $.extend( {}, obj);
        for (key in options) {
            options[key] = fn(options[key]);
        }
        return options;
    };

    $(document).ready(function() {
        var obj = {
            url: "http://jquery.com/",
            success: function() {alert("Hurrah!");},
            failure: function() {alert("Boohoo!");}
        };

        var myInstrumentation = function(option) {
            if ($.isFunction(option)) {
                return function() {
                    if (!this.count) this.count = 0;
                    this.count++;
                    option.call(this);
                }
            } else {
                return option;
            }
        };

        var newObj = newMap(obj, myInstrumentation);

        newObj.success.call(newObj);
        newObj.failure.call(newObj);
        newObj.success.call(newObj);

        alert("Total calls: " + newObj.count);

If so, then only a slight modification of the input object could cause
real problems, e.g.

        var obj = {
            url: "http://jquery.com/",
            success: function() {
                this.helper();
                alert("Hurrah!");
            },
            failure: function() {
                this.helper();
                alert("Boohoo!");
            },
            helper: function() {
                // do something here
            }
        };

Note that with this new function, count is also incremented in the
nested calls to the helper function.

Any time an object maintains its own state, or your mapping function
maintains its own, your code is at the mercy of the implementation of
the object supplied.  If there are only simple callback functions that
don't call other functions in the object, you might not have problems,
but in other cases, there could be problems.

You can see these in action at

    http://scott.sauyet.com/Javascript/Demo/2009-10-29a/1/  and
    http://scott.sauyet.com/Javascript/Demo/2009-10-29a/2/

As I said, I'm not convinced.  I think if you have a need for it, you
can write your own extension quite easily, but I can't quite see
something like this in the jQuery core.

Cheers,

  -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

It's very detailed, thank you for the demos! But I don't quite
understand the purpose of them. If you are saying $.map() shouldn't
work on objects because wrapping functions is not a good practice,
then $.map() should also not work on arrays. Here is why:

// options now is a sequence
var options = [ function() { this[1]() }}, function() { alert
('Oops') } ]

$.map() works on this "object", and it also causes the "problem" you
have illustrated. Actually, I don't perceive it as a "problem". What
you are doing is counting how many times the callback functions have
been called. Since some callback functions will call another callback
function, when three of them get called, it makes sense these callback
functions have been called six times in total.

Maybe I'm too dumb to get the essence of your demos, could you explain
more to me? Thanks.

On Oct 30, 12:55 pm, Scott Sauyet <scott.sau...@...> wrote:

> On Oct 29, 11:19 pm, gMinuses <gminu...@...> wrote:
>
> > But making map() functions work on hashes makes sense, so why rule
> > them out?
>
> I'm not convinced.  Is this the sort of usage, you are considering?:
>
>     var newMap = function(obj, fn) {
>         var options = $.extend( {}, obj);
>         for (key in options) {
>             options[key] = fn(options[key]);
>         }
>         return options;
>     };
>
>     $(document).ready(function() {
>         var obj = {
>             url: "http://jquery.com/",
>             success: function() {alert("Hurrah!");},
>             failure: function() {alert("Boohoo!");}
>         };
>
>         var myInstrumentation = function(option) {
>             if ($.isFunction(option)) {
>                 return function() {
>                     if (!this.count) this.count = 0;
>                     this.count++;
>                     option.call(this);
>                 }
>             } else {
>                 return option;
>             }
>         };
>
>         var newObj = newMap(obj, myInstrumentation);
>
>         newObj.success.call(newObj);
>         newObj.failure.call(newObj);
>         newObj.success.call(newObj);
>
>         alert("Total calls: " + newObj.count);
>
> If so, then only a slight modification of the input object could cause
> real problems, e.g.
>
>         var obj = {
>             url: "http://jquery.com/",
>             success: function() {
>                 this.helper();
>                 alert("Hurrah!");
>             },
>             failure: function() {
>                 this.helper();
>                 alert("Boohoo!");
>             },
>             helper: function() {
>                 // do something here
>             }
>         };
>
> Note that with this new function, count is also incremented in the
> nested calls to the helper function.
>
> Any time an object maintains its own state, or your mapping function
> maintains its own, your code is at the mercy of the implementation of
> the object supplied.  If there are only simple callback functions that
> don't call other functions in the object, you might not have problems,
> but in other cases, there could be problems.
>
> You can see these in action at
>
>    http://scott.sauyet.com/Javascript/Demo/2009-10-29a/1/ and
>    http://scott.sauyet.com/Javascript/Demo/2009-10-29a/2/
>
> As I said, I'm not convinced.  I think if you have a need for it, you
> can write your own extension quite easily, but I can't quite see
> something like this in the jQuery core.
>
> Cheers,
>
>   -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Robert Katić]

> But making map() functions work on hashes makes sense, so why rule
> them out?

There are at least three reasons why this is not a good idea:

1. $.map() is not a real "general purpose" map function. If callback
returns an array then its items will be values because in same cases
it is convenient that a callback can returns multiple values. So if
you make $.map() generic for all "hashes" than you would $.map()
generic for all sequences too.

2. If you make $.map() working with "hashes" too, then you have to
detect which object is a "hash" and which is a sequence. The only
think to do that is to check if the object.length is a number - weak!

3. for(var k in obj) newobj[k] = fn(obj[k])

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

> 1. $.map() is not a real "general purpose" map function. If callback
> returns an array then its items will be values because in same cases
> it is convenient that a callback can returns multiple values. So if
> you make $.map() generic for all "hashes" than you would $.map()
> generic for all sequences too.

Yes, $.map() could work for hashes like this:

var hash = { a: 1, b: 2 }

$.map( hash, function( val, key ) {
    if( key === 'a')
        return { c: 3, d: 4 };
    else
        return val;
});

And now hash is { c: 3, d: 4, b: 2 }. It doesn't conflict with
anything.

> 2. If you make $.map() working with "hashes" too, then you have to
> detect which object is a "hash" and which is a sequence. The only
> think to do that is to check if the object.length is a number - weak!

Actually, you don't have to differentiate between hashes and sequences
in js:

if( typeof arr === 'object' )
    for( var key in arr)

For sequences, the key will be 0, 1, 2 and so on. If you want to be
strict, you can rule out regexps:

if( typeof arr === 'object' && arr.constructor !== RegExp )

> 3. for(var k in obj) newobj[k] = fn(obj[k])

Like I said, it doesn't have the benefit of scoping.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Robert Katić]

> var hash = { a: 1, b: 2 }
>
> $.map( hash, function( val, key ) {
>     if( key === 'a')
>         return { c: 3, d: 4 };
>     else
>         return val;
>
> });
>
> And now hash is { c: 3, d: 4, b: 2 }. It doesn't conflict with
> anything.

Can you explain which objects you expect would extend the final
object, and which object would not?
(nodes are objects too)

> Actually, you don't have to differentiate between hashes and sequences
> in js:
>
> if( typeof arr === 'object' )
>     for( var key in arr)
>
> For sequences, the key will be 0, 1, 2 and so on. If you want to be
> strict, you can rule out regexps:
>
> if( typeof arr === 'object' && arr.constructor !== RegExp )

This is so wrong.
Maybe you can expect indexes in numerical order for Arrays, but still
Array.prototype is to often extended.
Also we have to iterate like sequence any array-like object (jQuery
objects, NodeLists,...).
.......

>
> > 3. for(var k in obj) newobj[k] = fn(obj[k])
>
> Like I said, it doesn't have the benefit of scoping.

If your argument is scoping, it is not enough.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

> Can you explain which objects you expect would extend the final
> object, and which object would not?
> (nodes are objects too)

I think it should make the following expression evaluate to true:

object && object.constructor === Object
( I'm not sure if it's strict enough, but what I mean is that the
object should be constructed by Object )

> This is so wrong.
> Maybe you can expect indexes in numerical order for Arrays, but still
> Array.prototype is to often extended.
> Also we have to iterate like sequence any array-like object (jQuery
> objects, NodeLists,...).

I think Array.prototype should never be extended, if it does, $.extend
() is the first one to be broken (at least for jQuery 1.3.2).

As for array-like objects, you can see how $.each() is implemented (I
think it's like a convention that if an object conforms the condition
I mentioned before, and has a "length" property, it should be treated
like an array)

var o = { length: 2, a : 1 }

$.each(o, function(i, v) {
        console.log(i, v)
})

This code prints

0, undefined
1, undefined

in firebug, which means it breaks the convention and the result is
expected.

> If your argument is scoping, it is not enough.

I don't quite understand what your are saying, could you be more
specific?

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

On Fri, Oct 30, 2009 at 8:37 AM, gMinuses <gminuses@...> wrote:
>> If your argument is scoping, it is not enough.
>
> I don't quite understand what your are saying, could you be more
> specific?

The main point, I think, is that you have not convinced either of us
of the worth of your proposed extension.  Can you describe some
real-world scenario that's fairly difficult to do now that would be
much easier with an extended $.map?  If you can, then there's room for
discussion about the benefits of the extension versus the costs of
adding to core and of the technical difficulties that might be
involved.

Maybe I'm just being dense, but I'm not really seeing the benefits.
$.map to me is a technique to convert one sequence of like items into
another sequence of like items (that might be entirely unlike the
original ones).  For instance, I might use it to extract the ids of a
sequence of nodes.  I don't see how I would want to use it for an
arbitrary object.

  -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

On Fri, Oct 30, 2009 at 2:22 AM, gMinuses <gminuses@...> wrote:
> It's very detailed, thank you for the demos! But I don't quite
> understand the purpose of them.

I was trying desperately to come up with some real-world use of your
suggestion, and noted that your example used callbacks, and I thought
you might want to use the technique to instrument your callback
methods in some manner.

> If you are saying $.map() shouldn't
> work on objects because wrapping functions is not a good practice,
> then $.map() should also not work on arrays. Here is why:
>
> // options now is a sequence
> var options = [ function() { this[1]() }}, function() { alert
> ('Oops') } ]

I'd contend that it's very difficult to see a real-world use of $.map
applied to functions.


> $.map() works on this "object", and it also causes the "problem" you
> have illustrated. Actually, I don't perceive it as a "problem". What
> you are doing is counting how many times the callback functions have
> been called. Since some callback functions will call another callback
> function, when three of them get called, it makes sense these callback
> functions have been called six times in total.

But "helper()" was not intended as a callback function.  It was an
implementation detail.  By accidentally mapping that function, we've
changed the semantics in a way we wouldn't have done if we'd chosen to
apply our transformation directly to the callbacks we cared about.

> Maybe I'm too dumb to get the essence of your demos, could you explain
> more to me? Thanks.

It's pretty clear you're not too dumb.  I'm just trying to figure out
how you'd want to use such an extended method.  The callbacks made me
wonder if this was the sort of detail you had in mind.

Cheers,

  -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Robert Katić]

> I think it should make the following expression evaluate to true:
>
> object && object.constructor === Object
> ( I'm not sure if it's strict enough, but what I mean is that the
> object should be constructed by Object )

This is technically a more complex problem then you think.
There was an John initiative to evolve an isObjectLiteral(obj)
http://gist.github.com/153271
I made an solution for it at http://gist.github.com/158651 that passes
all tests, but that shows how it complex it is too.
I think it would be an overhead. We have to avoid to make this
stuffs..

> I think Array.prototype should never be extended, if it does, $.extend
> () is the first one to be broken (at least for jQuery 1.3.2).

No. It array-like objects and other ones in different ways.

> As for array-like objects, you can see how $.each() is implemented (I
> think it's like a convention that if an object conforms the condition
> I mentioned before, and has a "length" property, it should be treated
> like an array)

I know exactly the $.each() implementation, and how I said, the only
way to detect array-like objects is to check the length property. It
is weak, but in case of $.each you normally know exactly witch
proprieties has an object.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

OK, the real-world use is this:

I'm writing a plugin for jquery that implements mvc pattern, and it
works like this:

Define a model:

$.mvc.model({
    myModel: {
        myMethod: function() {}
    }
});

Define a controller and call a model from the controller:

$.mvc.controller({
    myController: {
        myAction: function() {
            this.model('myModel').myMethod();
        }
    }
});

Here, the model & controller passed in by the user can't be stored
immediately, they need to extend instances constructed by Model &
Controller classes I defined somewhere else. So I need to iterate over
these objects' properties to modify them. For this snippet, there is
no need to wrap a function, so having $.map() works on objects won't
make a big difference, but consider this:

$.mvc.controller({
    myController: {
        myAction: function() {
            // Pass in a callback function,
            // once model has retrieved the data,
            // it'll pass the data as the first parameter
            // to the callback function
            this.model('myModel').myMethod(function(data) {
                 // data returned
            });
        }
    }
});

$.mvc.model({
    myModel: {
        myMethod: function() {
            // model passes the data by returning it directly
            return 'data';
        }
    },

    myAnotherModel: {
        myAnotherMethod: function() {
            this.ajax({ url: './', success: function(data) {
                // or by returning it in the ajax callback function
                return data;
            }})
        }
    }
});

This is when I need to modify user defined functions to support such
usage, and it comes the problem of scoping. It'll be very handy if
$.map() works on objects.

And I believe once an application gets more and more complicated,
it'll stand a good chance that some kind of hash-like objects need to
be modified.

Regards

On Oct 30, 9:38 pm, Scott Sauyet <scott.sau...@...> wrote:

> On Fri, Oct 30, 2009 at 2:22 AM, gMinuses <gminu...@...> wrote:
> > It's very detailed, thank you for the demos! But I don't quite
> > understand the purpose of them.
>
> I was trying desperately to come up with some real-world use of your
> suggestion, and noted that your example used callbacks, and I thought
> you might want to use the technique to instrument your callback
> methods in some manner.
>
> > If you are saying $.map() shouldn't
> > work on objects because wrapping functions is not a good practice,
> > then $.map() should also not work on arrays. Here is why:
>
> > // options now is a sequence
> > var options = [ function() { this[1]() }}, function() { alert
> > ('Oops') } ]
>
> I'd contend that it's very difficult to see a real-world use of $.map
> applied to functions.
>
> > $.map() works on this "object", and it also causes the "problem" you
> > have illustrated. Actually, I don't perceive it as a "problem". What
> > you are doing is counting how many times the callback functions have
> > been called. Since some callback functions will call another callback
> > function, when three of them get called, it makes sense these callback
> > functions have been called six times in total.
>
> But "helper()" was not intended as a callback function.  It was an
> implementation detail.  By accidentally mapping that function, we've
> changed the semantics in a way we wouldn't have done if we'd chosen to
> apply our transformation directly to the callbacks we cared about.
>
> > Maybe I'm too dumb to get the essence of your demos, could you explain
> > more to me? Thanks.
>
> It's pretty clear you're not too dumb.  I'm just trying to figure out
> how you'd want to use such an extended method.  The callbacks made me
> wonder if this was the sort of detail you had in mind.
>
> Cheers,
>
>   -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[Scott Sauyet-2]

On Fri, Oct 30, 2009 at 11:13 AM, gMinuses <gminuses@...> wrote:

> OK, the real-world use is this:
>
> I'm writing a plugin for jquery that implements mvc pattern, and it
> works like this:
>
> [ ... ]
>
> $.mvc.controller({
>    myController: {
>        myAction: function() {
>            // Pass in a callback function,
>            // once model has retrieved the data,
>            // it'll pass the data as the first parameter
>            // to the callback function
>            this.model('myModel').myMethod(function(data) {
>                 // data returned
>            });
>        }
>    }
> });
>
> $.mvc.model({
>    myModel: {
>        myMethod: function() {
>            // model passes the data by returning it directly
>            return 'data';
>        }
>    },
>
>    myAnotherModel: {
>        myAnotherMethod: function() {
>            this.ajax({ url: './', success: function(data) {
>                // or by returning it in the ajax callback function
>                return data;
>            }})
>        }
>    }
> });

So, to make sure I understand, you want to write a function (to be
used by an extended $.map) that wraps either myModel.myMethod or
myAnotherModel.myAnotherMethod to be called by myController.myAction,
which will supply a callback function to actually handle the actual
data returned by the methods.  Is that right?

First of all, good luck.  Whenever I've needed to get data from a
possibly synchronous or possibly asynchronous source, I've had to
define a method that accepts a callback and extend that in all cases,
even the otherwise synchronous ones.  Scoping seems a minor worry
compared to the synchronous/asynchronous dichotomy.  I'm really not
sure how you'll manage to do this.  Do you already have an
implementation?

But then the question becomes, how do you want $.map to work for your
object?  Does it modify the object in place?  (I would strongly argue
against this, not least because that would be at variance with how it
works for sequences.)  Is the model object allowed to have methods
that somehow escape the wrapping, like the helper function I defined
above?  Can the wrapper function ignore some properties?


> This is when I need to modify user defined functions to support such
> usage, and it comes the problem of scoping. It'll be very handy if
> $.map() works on objects.
>
> And I believe once an application gets more and more complicated,
> it'll stand a good chance that some kind of hash-like objects need to
> be modified.

Right now, as Robert pointed out, we're using the existence of a
numeric "length" property to determine if an object is array-like.
Are you going to prohibit model classes from having a property named
"length"?  If not, how would you distinguish the current array-like
behavior of working only with elt[0], elt[1], ... elt[length -1] and
your new behavior that would use any other named properties?

It strikes me that it's very easy to add a new $.objMap function if
you find it necessary for your project.  I certainly am not seeing any
argument for the widespread utility of adding this to $.map in the
core, nor do I see some possibly trivial implementation that makes it
such a minor addition that we can safely add it without worry.  Can
you supply either of those?

  -- Scott

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

[gMinuses]

Thanks! Now I'm convinced. I never thought it's going to be that
complicated. Maybe I just should stick with "for( key in object )".

On Oct 30, 10:42 pm, Robert Katić <robert.ka...@...> wrote:

> > I think it should make the following expression evaluate to true:
>
> > object && object.constructor === Object
> > ( I'm not sure if it's strict enough, but what I mean is that the
> > object should be constructed by Object )
>
> This is technically a more complex problem then you think.
> There was an John initiative to evolve an isObjectLiteral(obj)http://gist.github.com/153271
> I made an solution for it athttp://gist.github.com/158651that passes
> all tests, but that shows how it complex it is too.
> I think it would be an overhead. We have to avoid to make this
> stuffs..
>
> > I think Array.prototype should never be extended, if it does, $.extend
> > () is the first one to be broken (at least for jQuery 1.3.2).
>
> No. It array-like objects and other ones in different ways.
>
> > As for array-like objects, you can see how $.each() is implemented (I
> > think it's like a convention that if an object conforms the condition
> > I mentioned before, and has a "length" property, it should be treated
> > like an array)
>
> I know exactly the $.each() implementation, and how I said, the only
> way to detect array-like objects is to check the length property. It
> is weak, but in case of $.each you normally know exactly witch
> proprieties has an object.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@....
To unsubscribe from this group, send email to jquery-dev+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.