On Tuesday, 2012-06-05 at 16:06 , Brendan Eich wrote:
> 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 was coming from `Object.defineProperties`, but yeah any of that would make
more sense to me. Object.extend makes me think of <| instead.
>
> > 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.
>
Right I've being to extreme about it, but what I really meant is "where
possible".
> > > 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.
>
I'm sorry I messed up an example, I think what I meant was variation of this:
function definePrivates(target, pairs) {
let index = 0, length = pairs.length;
while (index <= length)
Object.defineProperty(target, pairs[index++], { value: pairs[index++] })
return target
}
defineProperties(target, [
name1, value1,
name2, value2
])
>
> > 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
> > > [email protected] <mailto:[email protected]>
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected] (mailto:[email protected])
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
