PDA

View Full Version : Ext.apply problem



extbio
22 Apr 2010, 11:27 AM
I think Ext.apply is having incorrect behavior based on documentation. For example, if you have:

var o = {a:1,c:3}, c = {a:3}, d = {c:5};
Ext.apply(o, c, d);
for(i in o) alert(i + ':' + o[i]);For the code above, most users probably would expect o == {a:3,c:3}, but instead the result is o == {a:3,c:5}. The defaults in Ext.apply actually overwrites existing values inside object. While it's arguable what should be the "correct" behavior here, the most commonly accepted rule in most programming situations is that default does not overwrite existing keys in object. This is the behavioral difference b/w defaults and config. Otherwise the default should be called config1, while the config be called config2.

This also creates a byproduct issue where if you pass Ext.apply(o, o, d), supposedly new o should == old o for all keys, but instead after the call new o == d for the keys they share.

Another issue is that only shallow copy's used here, so if user expected otherwise it would be an issue. That's not a bug, but a nice-to-note in documentation.

jay@moduscreate.com
26 Apr 2010, 5:24 AM
There is Ext.applyIf :)

extbio
26 Apr 2010, 5:41 AM
One needs to call Ext.applyIf(o, d) then Ext.apply(o, c) to do what Ext.apply(o, c, d) is supposed to do, clearly applyIf is not ideal here.

BTW I think this post should be removed - I didn't even know it was posted (I tried to post to Ext bug, but for some reason mods posted it to Ext help without notifying me), so I posted in Ext bug again. So this is a duplicate thread now.

jay@moduscreate.com
26 Apr 2010, 5:44 AM
It's not a bug because the behavior that you dislike is the intended behavior.

extbio
26 Apr 2010, 7:01 AM
It's not a bug because the behavior that you dislike is the intended behavior.

I've heard that one from Microsoft before.

I agree with Jamie's reply from http://www.extjs.com/forum/showthread.php?97709-OPEN-900-Ext.apply-Wrong-Behavior, if it ain't a bug in the code, then it's a bug with documentation. Fixing either one is fine - but don't tell me that in programming, the intended behavior of "defaults" is to overwrite existing values.