Both might make sense. I would say that the term
X exemplar
means that you use X to produce instances. Thus:
1. Using the constructor versus using the prototype to produce an instance.
“Constructors as classes” versus “prototypes as classes”.
2. Using a function versus using an object to produce an instance.
I like object exemplar and function exemplar, because they are the more direct
descriptions.
On Oct 31, 2011, at 2:17 , Allen Wirfs-Brock wrote:
>
> 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
>>
>>
>>
>
--
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
