Irakli Gozalishvili wrote:
I just want to (re)express my (and many others) concern about new
syntax. While Object.extend adds useful feature (Although I think
Object.define would be more appropriate name)
Object.define is the wrong name if the underlying operation at least for
data properties in the object passed as second aragument is, as it
should be, [[Put]] aka "assignment". Object.assign ain't great, though...
Object.set? [dherman]
Object.update? [mikeal]
I don't think new syntax is really necessary.
Agreed in this case.
I do think that new syntax needs a lot more justification then new
semantics. I also would argue that it's a good idea to alway make
syntax changes in a separate iteration from the one where associated
semantics have being introduced.
You wrote always and I must say "no". Some new semantics must come with
new syntax out of the box, e.g. let and const. You cannot expose APIs
for these (the ES5 Object API is not equivalent, we're talking about
binding forms). Modules are another example, especially the prefetching
form. Another example: generators.
That would allow both community and come tee to see these semantics in
practice and having more knowledge to decide what syntax sugar would
work best, if any new syntax even will turn out to be necessary.
If instead of "always" you wrote "where possible", I'd agree, but it's
still a bit too brain-off of a rule. In some cases I would go further
and say API only and never syntax! In other cases as noted, you can't
have new semantics without new syntax.
One of these things is installing private named properties upon an
existing object. As currently specified, those could not be
communicated to an extend function via an object literal because we
have disallowed any form of refection upon private named properties.
Object.extend could not see them on the literal object in order to
copy them. Trying to solve this problem by saying that Object.extend
has special reflection privileges would violate the encapsulation
that the non-relection on private name properties was intended to
provided.
But many other variations of this would do the job as well without a
new syntax:
Object.extend(target, privates(
name1, value1,
name2, value2
))
Is privates a constructor? This plausible, dherman suggested
Object.extend(target, source, privates) where privates is an array of
private name objects, even lighter weight I think.
Allen wrote:
Anther ES6 specific semantic that has always been part of the
mustache proposal is the correct binding of methods with super
references. I've described this many times. So I'll just describe it
again other than to reinforce that mustache is the great way to
dynamically associate super referencing method to an object without
running into the pitfalls that arise with the defineMethod
alternative. I see how with mustache we can live without defineMethld.
But omitting reflection APIs is pretty dangerous path to go with IMO.
JS has being great as it was always possible to fix things that were
not working for you. I have feeling that providing semantics only
through new syntax may take away this great power of JS.
JS does *not* provide APIs for all of its syntax, and never did. You
cannot "construct" statements or expressions other than by eval'ing a
string (no parse tree or AST reflection -- just one example).
Beware totalizing about syntax after semantics.
On Object.extend I think we agree, modulo best name.
/be
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Monday, 2012-06-04 at 09:45 , Brendan Eich wrote:
Kevin Smith wrote:
Thanks Dave,
Of the 3 use cases you mentioned, I think unique names are probably
sufficient for 1 and 3. For the second use case (an inaccessible
piece of data associated with an object), would not a weak map also be
appropriate?
No, WeakMaps have two problems we've covered in this list:
1. Less efficient than private names.
This matters when you can least afford it, and it matters for private
names used to program in the large using objects in JS. WeakMaps require
special GC handling and they're an extra object with internal mutable
state. Private name objects are flat, frozen, and can be optimized a lot
harder.
2. You cannot abstract property access:
function get(obj, prop) { return obj[prop]; }
works with a private name object referenced by prop. No such abstraction
can be done with a weak map.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
