Le 15/12/2011 18:17, John J Barton a écrit :
> (I know the language experts know all this, I'm spelling it out for
> fellow amateur 'classless' fans)
>
> After using (and liking) selfish I understand why prototypical
> inheritance via simple references is not an effective alternative to
> classes.
>
> The new Foo/Foo.prototype JavaScript idiom sets up a lookup table like
> this:
>
> [[Prototype]] -----> [[Prototype]] ------> [[Prototype]] -------> null
> myProps | parentProps grandProps
> |
> |
> [[Prototype]] ----+
> myProps
>
> (...)
>
> The reason is simple: 99% of the time you want base class functions to
> be inherited but not base class data values. In setting up
> "objects-that-will-be-classes" we can consciously avoid data values. I
> did not say this above, but most readers will imagine that all of the
> objects in the diagram above have only functions. That is essential
> what we mean when we thing of these objects as classes: no data
> properties.
WebIDL is taking a different direction [1]: the ECMAScript
representation of WebIDL attributes (like 'cookie' property of the
document object) is placed as an accessor property on the prototype
related to the given interface
(Object.getOwnPropertyDescriptor(HTMLDocument.prototype, 'cookie') is an
accessor property descriptor)
Consequently, objects used in the prototype layer have other things than
just functions.
(as far as I know, the only browser that currently conforms decently to
this model is IE9+)
> (...)
>
> JS projects address this issue by conventions and they can be
> successful. One in particular is 'selfish': the split between behavior
> and data is created by declaring behavior but implementing all data
> values imperatively in initialize(). It is convention only.
True. What WebIDL does is another convention.
> Class-based languages solve this by building the 'behavior' or
> function layer differently from the 'data' layer. The functions are
> placed in vtable data structures referencing base class vtables; data
> values are concatenated across all classes as properties for the instance.
>
> Classless solutions need a compelling solution to this issue, that is,
> an operation on a list of vanilla objects that yields a class-like
> object. Any such operation will fail in some cases, just like
> class-based solutions fail sometimes (when you really want to share
> data across classes). But a solution is needed for the 99% of the time
> when you don't want data sharing.
I think that traits will be another form of convention that will avoid
name collision (or assist the developer to deal with them explicitely
when they occur)
I agree with your intention, but not your conclusion. The language
provides a very generic interface when it comes to composition. Between
selfish, what WebIDL does and traits, we have at least 3 different
relevant approaches to composition, why should the language pick one
over all those possible?
ECMAScript 5, by providing
Object.{create|defineProperty|getPrototypeOf}, other introspection
methodsand and accessor properties (which were in some browsers but not
in ES3) helped advertise how the language works by showing the
fundamental constructs of the language to the programmer. It's been
implemented only recently (relatively to the history of the language and
that we've been stuck on ES3 for cross-browser compatibility concerns)
Some other fundamental constructs are on their way (proxies, reflection
API, WeakMaps, maps, sets, proto operator (x2), private names) and these
will certainly influence too how we think of and implement object
composition.
I'm not sure the language should decide now what approach to composition
it should favor... or if it should favor one (or more) at all! I think
we need at least (!) a year or two with all these features implemented,
running and used to see the big picture.
I agree to discuss the question but hope that no decision will be made
now. It sounds premature.
David
[1] http://www.w3.org/TR/WebIDL/#es-attributes
[2] http://www.w3.org/TR/html5/dom.html#htmldocument
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
