Enumerability is still important (was: Re: Object.define ==> Object.mixin??)

Herby Vojčík herby at mailbox.sk
Tue Dec 11 10:42:37 PST 2012



Allen Wirfs-Brock wrote:
> 3) I don't see any reason that it should be restricted to enumerable
> properties. If the intend is to deprecate enumerable along with for-in
> then we should be adding new functionality that is sensitive to the
> state of the enumerable attribute.
>
> Allen

Well, I had a real-world issue in which enumerability (and 
non-enumerability of methods) was still important.

In Amber, the Smalltalk implementation that compiles to JavaScript, 
there were issues[1], which failed with jQuery.ajax call. The object 
passed as options parameter was a HashedCollection, which mimicked JS 
object (keys as strings etc.), but the methods inherited via prototype 
striked back. JQuery read all properties (own as well as inherited), 
which makes sense, one can have templates and Object.create() from them, 
Object.defineProperty also honours inherited properties.

But some of the inherited properties make this fail or eat 100%CPU. 
Similar problem appeared with jQuery.css call (though I can't find an 
issue, it was probably only on the mailinglist).

The fix[2] was to make methods non-enumerable.

Now, jQuery takes enumerability (and I think not only jQuery does this) 
as a rough equivalent of "published" so it treats enumerables as visible 
part of object and non-enumerables are ignored for 
object-holding-some-data scenario.

If enumerable is to be deprecated, how should this be solved? If jQuery 
stops to honour inherited attributes, it would break Object.create()d 
data passed in. If not, one cannot safely pass in instance of the class 
with method, because methods will be included in the properties.

Thanks, Herby

[1] https://github.com/NicolasPetton/amber/issues/217, 
https://github.com/NicolasPetton/amber/issues/88
[2] https://github.com/NicolasPetton/amber/pull/202


More information about the es-discuss mailing list