On Mon, Nov 14, 2011 at 11:51 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Nov 14, 2011, at 8:48 AM, John J Barton wrote:
>
>> On Sun, Nov 13, 2011 at 9:49 PM, Brendan Eich <bren...@mozilla.com> wrote:
>>> On Nov 13, 2011, at 9:42 PM, Irakli Gozalishvili wrote:
>>>
>>> I think this discussion drifted into slightly diff direction.
>>> What I intended to say was that today all major frameworks use same patter
>>> to do subclassing. They all implement different APIs to do the following:
>>> function subclass() {
>>> // init ….
>>> }
>>> subclass.prototype = Object.create(superclass)
>>> Object.defineProperty(subclass.prototype, 'constructor', { value: subclass
>>> })
>>> subclass.prototype.method = function() {
>>> //...
>>> }
>>>
>>> Yes, this is the heart of the matter. Not freezing, not shallow vs. deep
>>> property copying (where deep must deal with closures at least).
>>
>> Sorry I don't understand.
>
> I was agreeing with Irakli that subclass/superclass wiring is primal to
> classes.
Irakli proposes a function; you are discussing classes. So perhaps
rather than agreeing with Irakli you are drawing a parallel: you like
the object created by Irakli's extend() and wish to take that into the
"class" discussion?
That's all fine. But I am focusing on the function vs (class) syntax
issue. That is where Irakli's "(why) classes" comes from.
>How one composes properties from various source objects is a different issue,
>not directly addressed by class syntax (yet). It is addressed by
>http://traitsjs.org/ and you can use an expression in the superclass position
>in the class head: class D extends Trait.create(...) {...}.
If we compare a |class| syntax
class D extends B adds P;
to Irakli's extend, we write:
var D = B.extend(P);
If both B and P can be expressions, then the forms are equivalent.
That is, both forms have to come up with an answer for how the B and P
are used in creating D.
>
>
>> Every function which accepts object
>> references and embeds its arguments in [[Prototype]] (either in the
>> return value or the instance created from the return value) faces the
>> copy-ish problem.
>
> Irakli was suggesting separating that from setting [[Prototype]] of a new
> subclass prototype object created at the same time, with constructor wired
> appropriately. That's what class syntax does at minimum.
Well he didn't suggest that, but it is a good idea ;-) His extend()
could be built out of a 'merge' and a 'subclass', something like:
https://gist.github.com/1365284
>
> You keep bringing in various extend alternatives, but these are separate from
> classes.
Yes, we agree here totally. But from my perspective I would say "You
keep bringing up classes, but these are separate from the
extend()-like functions".
>Yes, even in the case when the class body is non-empty: in that event the
>elements define properties on the new class prototype object, which shadow any
>properties on the base class prototype object. Shadow, not copy.
I think some of my previous comments mixed up issues related to
[[Prototype]] and issues related to properties. There are some
similarities and, to further confuse us, much of the existing practice
in this area uses property copies to set [[Prototype]] links via
Foo.prototype/new Foo. I'll try to be better.
In the form
class D extends B adds P;
or
var D = B.extend(P);
the properties on P shadow the properties on B. But the copy-ish
issue fall on B and P individually.
In Java/C++ languages B and P are highly constrained. Consequently the
copy-ish issue we discuss here don't apply. If want B and P to be
arbitrary expressions, then we have to face how the properties of D
relate to the properties of B and P.
I guess Allen's form is:
var D = B <| P;
where P is constrained to be a literal. I believe it still allows B to
have data values, which will be shared between instances of derived
objects.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
