Brandon Benvie wrote:
On 7/29/2013 10:03 AM, Kevin Smith wrote:
Are you arguing that non-enumerability is a useful encapsulation
mechanism?
I believe enumerability has a propensity to get in the way of
encapsulation.
Yes, because (among others) for-in loops that don't expect some
GUID-named thing will be unpleasantly surprised.
The main use case that I've seen for for-in and Object.keys is using
a plain object as a map. This use case is addressed more cleanly now
with Map and for-of, is it not?
It is safer to use a Map but it is not more convenient. I expect to
continue seeing people using object literals and mixing properties for
things like option objects for a long time to come.
Absolutely, and there's nothing wrong with that :-P. We shouldn't insist
on Map literals without lots of evidence of object literals gone wrong.
No such evidence in front of us, as far as I can tell.
Furthermore, developers today generally use underscores to "hide"
internal properties and methods. I'm not aware that it is a common
practice to bother with making these properties non-enumerable. Is it?
Right, and using GUIDs is just slightly better than this. The only
thing it does it provide uniqueness, who's value is mainly in
inheritance to prevent collisions in private fields. My experience is
that inheritance is usually done shallowly and these collisions are
rare and obvious when they happen.
Agreed.
GUIDs are strangely attractive but ugly. If we had a way to bind pretty
names to them, in the proposed extension, then it wouldn't just be "up
to debuggers". People console.log all the time.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
