[snip]
> >> I want to compose objects:
>> >> var result = cookUpTheBehavior(goodies, stuff) <|
>> initializeTheState(args);
>> >
>> > You want something else, then. Just because you want B does not mean A
>> is useless or less useful or not JavaScripty.
>> >
>> >> With a decent Object.extend() we'd have a clean way to build objects
>> without having to look up Crockford's web pages every time we try a
>> different variation.
>> >
>> > Object.extend is on the agenda. It's not the same as <|. Two different
>> tools for two or more different jobs.
>>
>
> I want these two tools to work together! I want a standard property
> cloner and a composition operation that creates objects from a behavior
> object and data object. Wouldn't that be nice?
>
I agree with this - at least in the sense that I think it might be an
appropriate time to take a higher level perspective of all the aspects of
JavaScript object definition and reuse. That seems to be a lot of what is
being discussed now from class literals to the <| operator to new <Object>
to traits. I understand the value of decomposing these ideas down into
orthogonal part which can be used independently and combined to create a
variety of useful abstractions. However, I think that creating something
cohesive is really important, and in the end we will want to provide a clear
path for the common cases.
I find it a problem that there is a standard pattern in JavaScript for
creating "classes" but there isn't a real name for it. We have constructor
functions and prototypes. Even the Rhino book is forced to say, "For lack of
a better term, I will use the word "class" informally in this chapter." Then
if you want to extend one of these things, you'll have to basically resort
to a library or some recipe of your own. It's black magic. And worse, all
the built-ins use the pattern, so we're basically going to have it around
forever.
I understand that this is sort of what <| is for, and it is potentially what
class literals are for, I guess my point is just that I think it should be a
high priority for es.next to result in some definitive way of saying:
1. create a thing Foo, including its constructor and at the very least
methods (including get/set methods)
2. create a Bar that extends Foo, including its constructor...
This is what Coffeescript provides with class and extend. I get the feeling
that using class would be too loaded. If class is going to be used it sounds
like people would like more than to have sugar for the existing pattern,
they would like more and they don't want to harm future proposals. I think
this is fair so I would say take the word "class" off the table. This is the
reason I had previously proposed <| as more of a generic extension operator.
It's already doing a lot of magic when it comes to functions and arrays.
I'm not sure exactly what the answer is, I'll try to think of something
better to propose, I just feel like hashing out the individual pieces like
<| and .{ and Object.extend etc. are all discussions that are worse off for
not discussing how they should all work together.
- Russ
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
