On Oct 30, 2011, at 5:47 PM, Axel Rauschmayer wrote:
> Thanks. But it is
> function exemplar versus object exemplar
> and not
> constructor exemplar versus prototype exemplar.
> Right?
>
I think when I originally introduced the exemplar term I contrasted function
exemplars (fExemplars) with object exemplars (oExemplars) because one is based
upon function expressions and the other is based upon object literals.
Both forms involved the use of "prototype" objects with a method named
"constructor".
Allen
> On Oct 31, 2011, at 1:29 , Allen Wirfs-Brock wrote:
>
>>
>> On Oct 30, 2011, at 1:12 PM, Axel Rauschmayer wrote:
>>
>>>> The object exemplar approach is just like self or selfish, except that it
>>>> builds upon features that are already in JS. Specifically, it uses the
>>>> new operator instead of a new method and it names the initialization
>>>> method "constructor" in order to tie into the object construction
>>>> mechanisms that already exist in JS.
>>>
>>>
>>> I’m trying to summarize, let me know if I made any mistakes:
>>>
>>> With the new new approach, we will have four kinds of exemplars (which are,
>>> roughly, “object factories”):
>>> 1. Object literals
>>
>> I'm not sure I would classify a simple, unnamed object literal as an
>> "exemplar". When I introduce this term I had in mind a construct for
>> expressing a named abstraction over a set of similar objects. The name part
>> is important because it is the name that allows talk about the set rather
>> than the individual object in the set. Object literals might be used as
>> constituent elements in the definition but are not by them selves exemplars.
>>
>>> 2. Function exemplars (constructor exemplars?)
>>> 3. Object exemplars (prototype exemplars?)
>>> 4. Object.create()
>>
>> I would consider (demote) Object.create to simply be part of the languages
>> reflection API rather than an actual language element. As such, we may not
>> need to include it in this consideration.
>>>
>>> The proto operator lets us use inheritance between any two #2 or #3
>>> exemplars. That ensures compatibility with legacy code. Since instanceof
>>> works for both kinds of examplars as well, the only possible hazard that is
>>> left is function exemplar code trying to access ObjectExamplar.prototype,
>>> e.g. to add new methods.
>>>
>>> Object exemplar example:
>>>
>>> const Person = {
>>> constructor(name) {
>>> this.name = name;
>>> },
>>> describe() {
>>> return "Person called "+this.name;
>>> }
>>> };
>>> const Employee = Person <| {
>>> constructor(name, title) {
>>> super.constructor(name);
>>> this.title = title;
>>> },
>>> describe() {
>>> return super.describe()+" ("+this.title+")";
>>> }
>>> };
>>>
>>> let jane = new Employee();
>>> console.log(jane instanceof Employee); // true
>>>
>>> If object exemplars were to become part of ES.next, we would not need class
>>> literals.
>>>
>>> --
>>> Dr. Axel Rauschmayer
>>> [email protected]
>>>
>>> home: rauschma.de
>>> twitter: twitter.com/rauschma
>>> blog: 2ality.com
>>>
>>>
>>>
>>>
>>
>>
>
> --
> Dr. Axel Rauschmayer
> [email protected]
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
