Discuss
  • new <Object>

new <Object>

# Jake Verbaten (14 years ago)

is there any kind of proposal for syntax that is like :

var proto = { method: function() { }, constructor: function(someValue) { this.things = someValue } };

var o = new proto(someValue); Object.getPrototype(o) === proto; // true

basically defining how new operates on an object (that is to represent the prototype). It is basically equivelant to

var Constructor = function () { ... } constructor.prototype = { method: ... constructor: Constructor }

var o = new Constructor(someValue);

To me personally the whole duplication the Constructor on Constructor.prototype.constructor and having .prototype on a function is less elegant.

Initial concerns with such syntax :

  • new { ... }(parameters) may be difficult to parse
  • new protoObj.call(...) is not going to work (protoObj does not have Function.prototype in it's prototype chain), should it work?
  • new protoObj(); should probably throw an error if protoObj.constructor is not defined.
  • should we invoke a constructor property of a protoObj that is not it's own property
  • the new operator is confusing enough as it is

Advantages:

  • this syntax would map more closely with the proposed declarative class syntax. So class could just be a sugar for generating objects you can invoke with new.
  • For any well formed existing code (where .prototype.constructor is set) new existingObject() should generate a new object with existingobject as it's prototype and having called the nearest constructor property
  • constructor property is optional so new someObject is just sugar for Object.create(someObject)
# Axel Rauschmayer (14 years ago)

From: Jake Verbaten <raynos2 at gmail.com> Subject: new <Object> Date: October 11, 2011 20:53:58 GMT+02:00 To: es-discuss <es-discuss at mozilla.org>

is there any kind of proposal for syntax that is like: [...] var o = new proto(someValue);

There has been a long discussion here, a few months ago. I’ve tried to summarize it here: www.2ality.com/2011/06/prototypes-as-classes.html

The discussion ended with the following conclusion:

  • Pro: Yes, it would make things simpler. I would even argue that new-style classes being able to extend old-style classes would be enough. Furthermore, Python has successfully switched from one style of class to another one.

  • Contra: It would introduce a second protocol for inheritance and it would probably not find universal acceptance (some people find prototypes-as-classes more elegant, others like constructor functions). Furthermore, class literals practically look and feel like prototypes-as-classes, so that it’s a good enough solution for me.

Axel

# Jake Verbaten (14 years ago)

On Tue, Oct 11, 2011 at 8:11 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

*From: *Jake Verbaten <raynos2 at gmail.com> *Subject: *new <Object> *Date: *October 11, 2011 20:53:58 GMT+02:00 *To: *es-discuss <es-discuss at mozilla.org>

is there any kind of proposal for syntax that is like:

[...]

var o = new proto(someValue);

There has been a long discussion here, a few months ago. I’ve tried to summarize it here: www.2ality.com/2011/06/prototypes-as-classes.html

The discussion ended with the following conclusion:

  • Pro: Yes, it would make things simpler. I would even argue that new-style classes being able to extend old-style classes would be enough. Furthermore, Python has successfully switched from one style of class to another one.

  • Contra: It would introduce a second protocol for inheritance and it would probably not find universal acceptance (some people find prototypes-as-classes more elegant, others like constructor functions). Furthermore, class literals practically look and feel like prototypes-as-classes, so that it’s a good enough solution for me.

I dont think having both new <Object> and new <Function> in the language

will cause any conflicts. It's the same as claiming that having both declarative class and new <Function> would cause "confusion".

class literals look the same but literal declaration are a right pain for any kind of meta programming. I can't take an existing object and turn it into a "class" without using eval.

# Axel Rauschmayer (14 years ago)

I dont think having both new <Object> and new <Function> in the language will cause any conflicts. It's the same as claiming that having both declarative class and new <Function> would cause "confusion".

I wouldn’t mind either, but there will be two ways of doing things then (and that’s only a positive in the Perl world ;-).

class literals look the same but literal declaration are a right pain for any kind of meta programming. I can't take an existing object and turn it into a "class" without using eval.

Can you elaborate?

It don’t think, it is that bad: Currently, you have a clear separation of concerns between the prototype and the constructor. However, these things are cumbersome:

  1. Assembling a class
  2. Subclassing
  3. Constructor chaining, super method calls
  4. Instanceof works with a name of an entity that only existed at instantiation time and is only weakly connected to an instance after that.

Sect. 3 in [1] goes into more detail on how prototypes-as-classes would automatically make these things simpler.

But in ECMAScript.next, class literals and super references fix 1-3 (and #4 is not that hard to live with). Superficially, things will be easy to handle. Under the hood, it’s a little more complicated, but it should help to concentrate on what role the constructor function plays and what role the prototype.

[1] www.2ality.com/2011/06/prototypes-as-classes.html

# Jake Verbaten (14 years ago)

On Tue, Oct 11, 2011 at 8:58 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

I dont think having both new <Object> and new <Function> in the language will cause any conflicts. It's the same as claiming that having both declarative class and new <Function> would cause "confusion".

I wouldn’t mind either, but there will be two ways of doing things then (and that’s only a positive in the Perl world ;-).

class literals look the same but literal declaration are a right pain for any kind of meta programming. I can't take an existing object and turn it into a "class" without using eval.

Can you elaborate?

Let's say I have object/class A and object/class B, I want a new class that is the union of A and B. (basically a mixin).

There is no way of saying C = union(A,B) without using your standard functions and function.prototype.

Where as with prototypes as classes it would be as simple as saying var C = Object.extend({}, A, B) (for some value of Object.extend)

There are other examples of meta programming you cannot do with class declaration (without using eval. You can do anything with eval)

Not to mention that es:h classes desugar to functions as classes rather then prototypes as classes (the latter doesn't exist yet).

I'd just think implementing prototypes as classes has very little to loose as long as we dont go and fix all the existing objects (Object.prototype, Function.prototype, String.prototype, etc)

# Axel Rauschmayer (14 years ago)

class literals look the same but literal declaration are a right pain for any kind of meta programming. I can't take an existing object and turn it into a "class" without using eval.

Can you elaborate?

Let's say I have object/class A and object/class B, I want a new class that is the union of A and B. (basically a mixin).

There is no way of saying C = union(A,B) without using your standard functions and function.prototype.

Where as with prototypes as classes it would be as simple as saying var C = Object.extend({}, A, B) (for some value of Object.extend)

There are other examples of meta programming you cannot do with class declaration (without using eval. You can do anything with eval)

It will be more work, but the prototypes are still there and can be combined as you describe above. I don’t think you need eval().

Not to mention that es:h classes desugar to functions as classes rather then prototypes as classes (the latter doesn't exist yet).

The under-the-hood manipulations will be a bit more complicated, but the end result will always have the clear separation of responsibilities between constructor and prototype.

I'd just think implementing prototypes as classes has very little to loose as long as we dont go and fix all the existing objects (Object.prototype, Function.prototype, String.prototype, etc)

I guess that is the rub, reworking the standard types and all the code that uses Class.prototype.* instead of Class.*. It would have to be done to make things clean again and it would be too much work.

# Jake Verbaten (14 years ago)

Yes the prototypes are still there. But that means im just using es3 constructs. Es:harmony class literals only offer declarative sugar.

I'm not proposing we change any of the existing Class.prototype.* code. I just propose that rather then throwing an error on new <Object> we make it

work.

This basically means we have three constructs for doing "classes". we can even have declarative desugar to prototypes as classes, but thats optional.

We basically give people more choice. I'd say it's worth implementing merely for having classes desugar to something with a more sensible 1<->1 mapping.

On Oct 11, 2011 9:22 PM, "Axel Rauschmayer" <axel at rauschma.de> wrote:

class literals look the same but literal declaration are a right pain

for any kind of meta progr... It will be more work, but the prototypes are still there and can be combined as you describe above. I don’t think you need eval().

Not to mention that es:h classes desugar to functions as classes rather

then prototypes as class... The under-the-hood manipulations will be a bit more complicated, but the end result will always have the clear separation of responsibilities between constructor and prototype.

I'd just think implementing prototypes as classes has very little to loose

as long as we dont go...

I guess that is the rub, reworking the standard types and all the code that uses Class.prototype.* instead of Class.*. It would have to be done to make things clean again and it would be too much work.

-- Dr. Axel Rauschmayer axel at rauschma.de, twitter.com/rauschma home: rauschma.de blog: 2ality.co...

# Allen Wirfs-Brock (14 years ago)

On Oct 11, 2011, at 11:53 AM, Jake Verbaten wrote:

is there any kind of proposal for syntax that is like :

var proto = { method: function() { }, constructor: function(someValue) { this.things = someValue } };

var o = new proto(someValue); Object.getPrototype(o) === proto; // true

It's still on my radar. Most recently see esdiscuss/2011-September/016736

It isn't an accepted Es.next proposal, but I suspect there is wiggle room for it to slip in as part of the enhanced object literals/class support if there is sufficient interest.

I haven't pushed it too hard yet because I think we have more pressing issues to get resolved and I didn't want this to become a distraction. However, I probably should write up a strawman for it.

# Allen Wirfs-Brock (14 years ago)

On Oct 11, 2011, at 1:46 PM, Jake Verbaten wrote:

Yes the prototypes are still there. But that means im just using es3 constructs. Es:harmony class literals only offer declarative sugar.

I'm not proposing we change any of the existing Class.prototype.* code. I just propose that rather then throwing an error on new <Object> we make it work.

This basically means we have three constructs for doing "classes". we can even have declarative desugar to prototypes as classes, but thats optional.

We basically give people more choice. I'd say it's worth implementing merely for having classes desugar to something with a more sensible 1<->1 mapping.

I agree that new <object> would be a useful feature for ES developers who want to create prototypal inheritance based abstractions. And along with super support in ES.next it really enables true self-style programming.

However, I think that talking about such abstractions as "classes" creates confusions and a unwarranted sense of competition with class declarations. t isn't an either/or situations where we have to choose between primitive compositional operators or declarative syntax for the most common class abstraction patterns.

ES objects, new <object>, new <function>, object literals, <|, and .{ would provide a core set of primitives that can be used support of metaprogramming implementations of a wide spectrum of object abstraction and composition models. This is a good think and arguably an important aspect of using ES as the foundation language of the web platform.

# Jake Verbaten (14 years ago)

Agreed. all of these can live side by side. There is no reason for new <Object> to compete declarative classe s.

I merely caused confusion using the phrase "prototypes as classes" instead of new <Object>.

as a side note whislt you mentioned .{ and |> I would like to have

programmatic, non declaritive alternatives for those as well. This might warrant another thread.

On Oct 11, 2011 11:12 PM, "Allen Wirfs-Brock" <allen at wirfs-brock.com> wrote:

On Oct 11, 2011, at 1:46 PM, Jake Verbaten wrote: > Yes the prototypes are

still there. But that m... I agree that new <object> would be a useful feature for ES developers who

want to create prototypal inheritance based abstractions. And along with super support in ES.next it really enables true self-style programming.

However, I think that talking about such abstractions as "classes" creates confusions and a unwarranted sense of competition with class declarations. t isn't an either/or situations* *where we have to choose between primitive compositional operators or declarative syntax for the most common class abstraction patterns.

ES objects, new <object>, new <function>, object literals, <|, and .{ would

provide a core set of primitives that can be used support of metaprogramming implementations of a wide spectrum of object abstraction and composition models. This is a good think and arguably an important aspect of using ES as the foundation language of the web platform.

# Axel Rauschmayer (14 years ago)

I absolutely love it for its conceptual beauty, but the primary goal should be to establish a single dominant way of doing inheritance in JavaScript.

One feature that doesn’t yet fit into my "pure OO" universe are factory functions/methods (I used frequently used factory methods in Java):

  1. They give better names to constructors.
  2. They allow one to return an instance of a subclass.

Example of #1: new Point.zero() Example of #2: Expression.parse()

How would you add that to JavaScript?

# Jake Verbaten (14 years ago)

Point.zero = function () { return (new Point).{ x: 0, y: 0 }; }

why are factory methods special? they are just methods.

On Oct 11, 2011 11:26 PM, "Axel Rauschmayer" <axel at rauschma.de> wrote:

I absolutely love it for its conceptual beauty, but the primary goal should be to establish a single dominant way of doing inheritance in JavaScript.

One feature that doesn’t yet fit into my "pure OO" universe are factory functions/methods (I used frequently used factory methods in Java):

  1. They give better names to constructors.
  2. They allow one to return an instance of a subclass.

Example of #1: new Point.zero() Example of #2: Expression.parse()

How would you add that to JavaScript?

On Oct 12, 2011, at 0:12 , Allen Wirfs-Brock wrote: > > On Oct 11, 2011, at

1:46 PM, Jake Verbate...

-- Dr. Axel Rauschmayer axel at rauschma.de, twitter.com/rauschma home: rauschma.de blog: 2ality.com

# Axel Rauschmayer (14 years ago)

If they are just a different way of initializing, then I love Smalltalk’s approach of separating instantiation and initialization. E.g. new Point.zero() would actually mean (note: in normal JS, I always write parens after a new-invoked function, but here it works well) (new Point).zero()

(new Point) just creates an empty instance. Several initialization methods set them up correctly.

What is missing from this approach is how to encapsulate the use of a subclass (as in Expression.parse which might return an instance of any subclass of Expression, depending on what is parsed – a literal, a binary operator, etc.). But maybe that should just be a function, e.g. parseExpression().

# Jake Verbaten (14 years ago)

As for expression.parse, any constructor or initializer is still a function therefore it can return an object thats not this.

This would be a good usecase for overwriting the [[Prototype]] with a new value.

I dont know what sugar or syntax other languages with "factory methods" offer which makes the ordeal significantly more elegant.

On Oct 11, 2011 11:38 PM, "Axel Rauschmayer" <axel at rauschma.de> wrote:

If they are just a different way of initializing, then I love Smalltalk’s approach of separating instantiation and initialization. E.g. new Point.zero() would actually mean (note: in normal JS, I always write parens after a new-invoked function, but here it works well) (new Point).zero()

(new Point) just creates an empty instance. Several initialization methods set them up correctly.

What is missing from this approach is how to encapsulate the use of a subclass (as in Expression.parse which might return an instance of any subclass of Expression, depending on what is parsed – a literal, a binary operator, etc.). But maybe that should just be a function, e.g. parseExpression().

# Kevin Reid (14 years ago)

On Oct 11, 2011, at 18:29, Jake Verbaten wrote:

Point.zero = function () { return (new Point).{ x: 0, y: 0 }; }

why are factory methods special? they are just methods.

I agree with "things should be just methods", but this particular pattern doesn't work for always-frozen types.

# Jake Verbaten (14 years ago)

So basically your saying that the only function that can alter an object before its frozen is the constructor, thats why we need multiple constructors?

You'll have to subclass with another constructor or come up with syntax for multiple constructors.

On Oct 11, 2011 11:46 PM, "Kevin Reid" <kpreid at switchb.org> wrote:

On Oct 11, 2011, at 18:29, Jake Verbaten wrote: > Point.zero = function () {

return (new Point)...

I agree with "things should be just methods", but this particular pattern doesn't work for always-frozen types.

-- Kevin Reid switchb.org/kpreid

# Kevin Reid (14 years ago)

On Oct 11, 2011, at 18:51, Jake Verbaten wrote:

On Oct 11, 2011 11:46 PM, "Kevin Reid" <kpreid at switchb.org> wrote:

On Oct 11, 2011, at 18:29, Jake Verbaten wrote:

Point.zero = function () { return (new Point)... I agree with "things should be just methods", but this particular pattern doesn't work for always-frozen types.

So basically your saying that the only function that can alter an object before its frozen is the constructor, thats why we need multiple constructors?

You'll have to subclass with another constructor or come up with syntax for multiple constructors.

Well, in JavaScript you can always Object.create(Point.prototype, ...).

In Java, for example, the ability to have multiple constructors can be very convenient for that type of use case; but it always can be replaced with factory methods and a private constructor with more parameters.

Actually, my original remark may be off-base anyway; I haven't followed the discussion well enough. If the ".{" syntax returns a new object rather than mutating one, then I was confused.

# Allen Wirfs-Brock (14 years ago)

On Oct 11, 2011, at 4:03 PM, Kevin Reid wrote:

Well, in JavaScript you can always Object.create(Point.prototype, ...).

In Java, for example, the ability to have multiple constructors can be very convenient for that type of use case; but it always can be replaced with factory methods and a private constructor with more parameters.

Actually, my original remark may be off-base anyway; I haven't followed the discussion well enough. If the ".{" syntax returns a new object rather than mutating one, then I was confused.

No, you were exactly correct. .{ mutates the object to the left of the .

Point.zero = function () { return (new Point).{ x: 0, y: 0 }; }

return (new Point).{x: 0, y: 0};

is essentially short hand for:

let p = new Point. p.x = 0; p.y = 0; return p;

of course, you entire definition above could have alternatively been written as:

Point.{zero() {return (new Point).{x:0, y: 0}};

# Axel Rauschmayer (14 years ago)

From: Allen Wirfs-Brock <allen at wirfs-brock.com> Subject: Re: new <Object> Date: October 11, 2011 23:50:14 GMT+02:00 To: Jake Verbaten <raynos2 at gmail.com> Cc: es-discuss <es-discuss at mozilla.org>

It's still on my radar. Most recently see esdiscuss/2011-September/016736

It isn't an accepted Es.next proposal, but I suspect there is wiggle room for it to slip in as part of the enhanced object literals/class support if there is sufficient interest.

I haven't pushed it too hard yet because I think we have more pressing issues to get resolved and I didn't want this to become a distraction. However, I probably should write up a strawman for it.

A few ideas, also in the vein of “not wanting this to be a distraction”:

  • I would feel better about “instantiable prototypes” (IPs) if there was a clean migration path. Then people could start using IPs and it wouldn’t matter whether the standard classes were constructors or IPs. See check list, below.
  • What will happen to class methods? That’s the only advantage that constructors currently have. But I’ve always felt uneasy about them (they felt to Java-ish where they are used to mimic functions). I suspect that most of these methods are better put into a module (especially Object.*).
  • Wish – factory methods that can return subclasses. Not sure how that fits into the picture; it’s possible that using a function is fine as a work-around.
  • Wish – named constructors. For that, it would be nice if we could have syntactic sugar such as new Point.zero() meaning that Point is just instantiated and then zero() initializes it. With that notation, new Point(...) actually means new Point.constructor(…) I know that this would wreak havoc with legacy compatibility, but maybe there is a similar solution that would not.

Check list of mechanisms that need to generic.

  • “new” works the same for IPs and constructors.
  • “instanceof” needs a similarly generic definition.
  • Subclassing. There is no need to let a constructor “subclass” a prototype, but the inverse should be doable. Then <| won’t work. Instead, maybe a method that is used in both cases?

MyConstructor.extendedBy(function(...) {…}); MyConstructor.extendedBy({…}); MyPrototype.extendedBy({…});

Alternatively, the following MyConstructor <| { … } could be syntactic sugar for MyConstructor.prototype <| { … }

Rationale: Would a function ever be a prototype of something else but a function? Thus, if the RHS is not a function, it desugars in the above manner.

# Irakli Gozalishvili (14 years ago)

I think we should just forget about new keyword, prototype property all togather and move towards something more simple:

var proto = { method: function() { }, new: function() { var self = Object.create(this); this.initialize.apply(self, arguments); return self; }, initialize: function(someValue) { this.things = someValue } }

var o = proto.new(someValue);

Of course with a help of library that would not require as much boilerplate: Gozala/selfish

-- Irakli Gozalishvili Web: www.jeditoolkit.com Address: 29 Rue Saint-Georges, 75009 Paris, France (goo.gl/maps/3CHu)

# Jake Verbaten (14 years ago)

I do the same with

Object.prototype.new = function () { var o = Object.create(this); o.constructor && o.constructor.apply(o, arguments); return o; }

However rather then calling proto.new(); I would like var o = new proto(); and o instanceof proto to work

On Oct 17, 2011 9:17 AM, "Irakli Gozalishvili" <rfobic at gmail.com> wrote:

I think we should just forget about new keyword, prototype property all togather and move towards something more simple:

var proto = { method: function() { }, new: function() { var self = Object.create(this); this.initialize.apply(self, arguments); return self; }, initialize: function(someValue) { this.things = someValue } }

var o = proto.new(someValue);

Of course with a help of library that would not require as much boilerplate: Gozala/selfish

-- Irakli Gozalishvili Web: www.jeditoolkit.com Address: 29 Rue Saint-Georges, 75009 Paris, France goo.gl/maps/3CHu

On Tuesday, 2011-10-11 at 20:53 , Jake Verbaten wrote:

is there any kind of proposal for syntax that is like : > > var proto = { > method: function(...

# Irakli Gozalishvili (14 years ago)

-- Irakli Gozalishvili Web: www.jeditoolkit.com Address: 29 Rue Saint-Georges, 75009 Paris, France (goo.gl/maps/3CHu)

On Monday, 2011-10-17 at 11:16 , Jake Verbaten wrote:

I do the same with Object.prototype.new = function () { var o = Object.create(this); o.constructor && o.constructor.apply(o, arguments); return o; } However rather then calling proto.new(); I would like var o = new proto();

May I ask why (less syntax in language is better no) ?

and o instanceof proto to work

You have proto.isPrototypeOf(o) instead.

# Allen Wirfs-Brock (14 years ago)

On Oct 16, 2011, at 12:51 PM, Axel Rauschmayer wrote:

From: Allen Wirfs-Brock <allen at wirfs-brock.com> Subject: Re: new <Object> Date: October 11, 2011 23:50:14 GMT+02:00 To: Jake Verbaten <raynos2 at gmail.com> Cc: es-discuss <es-discuss at mozilla.org>

It's still on my radar. Most recently see esdiscuss/2011-September/016736

It isn't an accepted Es.next proposal, but I suspect there is wiggle room for it to slip in as part of the enhanced object literals/class support if there is sufficient interest.

I haven't pushed it too hard yet because I think we have more pressing issues to get resolved and I didn't want this to become a distraction. However, I probably should write up a strawman for it.

A few ideas, also in the vein of “not wanting this to be a distraction”:

  • I would feel better about “instantiable prototypes” (IPs) if there was a clean migration path. Then people could start using IPs and it wouldn’t matter whether the standard classes were constructors or IPs. See check list, below.
  • What will happen to class methods? That’s the only advantage that constructors currently have. But I’ve always felt uneasy about them (they felt to Java-ish where they are used to mimic functions). I suspect that most of these methods are better put into a module (especially Object.*).

Self seems go get along fine without them. It it's case functions that you might assign to a class method (constants, alternative factories) are just instance methods on the IP.

  • Wish – factory methods that can return subclasses. Not sure how that fits into the picture; it’s possible that using a function is fine as a work-around.

they can, just use new this; within such factories. Example using a fExemplar:

let Klass = function () { /* normal constructor */ this.iamAKlass = true; }.constructor.{ prepared() { preprocessArguments(args); instance = new this(); this.prepareInstance(instance); return instance; }, prepareInstance(obj) { obj.iamPrepared = true; } };

let SubKlass = Klass <| function () { super.constructor(); this.iamASubKlass = true; };

let k = new Klass; k.hasOwnProperty('iamAKlass'); //true k.hasOwnProperty('iamPrepared'); //false

let pk = Klass.prepared(); pk.hasOwnProperty('iamAKlass'); //true pk.hasOwnProperty('iamPrepared'); //true

let s = new SubKlass; s.hasOwnProperty('iamAKlass'); //true s.hasOwnProperty('iamASubKlass'); //true s.hasOwnProperty('iamPrepared'); //false

let ps = SubKlass.prepared(); ps.hasOwnProperty('iamAKlass'); //true ps.hasOwnProperty('iamASubKlass'); //true ps.hasOwnProperty('iamPrepared'); //false

  • Wish – named constructors. For that, it would be nice if we could have syntactic sugar such as new Point.zero() meaning that Point is just instantiated and then zero() initializes it. With that notation, new Point(...) actually means new Point.constructor(…) I know that this would wreak havoc with legacy compatibility, but maybe there is a similar solution that would not.

let Klass = function (arg) { this.state = arg; }.constructor.{ zero() { return new this(0) } } };

let k = Klass.zero();

let SubKlass = Klass <| functiion(arg) {super.constructor(arg)};

let s = SubKlass.zero(); s.state; //0 s instanceof SubKlass; //true

(BTW, all of the above is just new skin on old Smalltalk patterns where this style of class methods are old hat)

Check list of mechanisms that need to generic.

  • “new” works the same for IPs and constructors.
  • “instanceof” needs a similarly generic definition.
  • Subclassing. There is no need to let a constructor “subclass” a prototype, but the inverse should be doable. Then <| won’t work. Instead, maybe a method that is used in both cases?

I don't agree. If you are going to have multiple kinds of named exemplars (and we already do) then the kind of exemplar is one of the things that you will generally want to abstract away in normal usage. Consider an exemplar E. The choice of exemplar style of E was an implementation decision that shouldn't be visible to users of E. I shouldn't have to know what kind of exemplar it is in order to specialize it. E <| anyExempalr should work regardless of how E was implemented.