new <Object>

Jake Verbaten raynos2 at gmail.com
Tue Oct 11 13:08:37 PDT 2011


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)


> 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] http://www.2ality.com/2011/06/prototypes-as-classes.html
>
> --
> Dr. Axel Rauschmayer
>
> axel at rauschma.de
> twitter.com/rauschma
>
> home: rauschma.de
> blog: 2ality.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111011/52e998e2/attachment-0001.html>


More information about the es-discuss mailing list