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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
