On Thu, Oct 13, 2011 at 6:08 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
>
> On Oct 13, 2011, at 5:08 PM, John J Barton wrote:
>
>
>
> On Thu, Oct 13, 2011 at 4:26 PM, Allen Wirfs-Brock
> <al...@wirfs-brock.com>wrote:
>
>>
>>
>> I still haven't found a really compelling use case for a non-literal <|
>> RHS and a good definition for object cloning is still a nut to crack. But
>> both plausibly might occur.
>>
>
> The use case is the same as Object.extend(): the flexible construction of
> objects from objects. Object.extend() is used in two ways: 1) To compose
> behaviors, and 2) To compose state properties. At present we no simple way
> to go from 1 and 2 to 1+2. Instead we have to do a dance with a function
> and its .prototype property (or I guess we can mutate __proto__ ;-).
>
>
> I'm not certain where you see [[Prototype]] modification entering into what
> you are describing,
>
I have not said it did; in fact I said it did not. Mutating [[Prototype]] is
not the issue; Literal RHS is the issue.
> but I'll assuming that for 1 you want to compose the behaviors into a
> prototype and that for 2 you want the state to compose into an instance that
> references the prototype. This all seems like it is expressible in ES5 user
> level code, using some subset and combination of Object.getOwnPropertyNames,
> Object.getOwnPropertyDescriptor, Object.create, and
> Object.defineProperty/defineProperties. You would probably want to define
> some helper functions
>
Sure we can, using way less than ES5, because we already do all of this
hackery.
>
> And obviously a good definition of object cloning would be needed for
> Object.extend() and it would answer your second objection.
>
>
> I don't think they are the same thing at all. Object.extend is just
> copying properties into a preexisting object. It is not trying to create an
> new exact duplicate (except for object identify) of an existing object that
> is a work-alike equivalent of the original object. For cloning you have
> non-property based object characteristics and application specific identity
> invariants that complicate matters. It isn't clear that these issues occur
> in the same way for Object.extend
>
You lost me here. I should have objected to the requirement of a object
cloning definition I guess.
The particular variant of Object.extend() I use does not overwrite the LHS.
It creates a new object, copies the LHS into it, then the RHS, then returns
it. So the LHS can be a literal, for example to override some functions in
the RHS. I think of it as a function representing binary operator. (Other
versions extend() do other things, exactly why a standard would be good, but
leave that for now).
Now let's invent Object.make(protoLink, props) (or createSimple()...). Let's
cause make() to give the same result as <| for any pair of values valid for
<|. Now when props is an object expression, what is the result of
Object.make(protoLink, props)? I would want
var a1 = Object.make(Object.prototype, a)
to be the same structure as
var a2 = Object.extend({}, a);
This is what I meant by "obviously a good definition ... would be needed for
extend and it would answer you second objection": whatever rules apply to
the RHS in extend() should apply to the RHS in make().
And of course I would like this to be true for <| as well.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
