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 >>>> a...@rauschma.de >>>> >>>> home: rauschma.de >>>> twitter: twitter.com/rauschma >>>> blog: 2ality.com >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> Dr. Axel Rauschmayer >> a...@rauschma.de >> >> home: rauschma.de >> twitter: twitter.com/rauschma >> blog: 2ality.com >> >> >> > -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss