prototype focus

Quildreen Motta quildreen at gmail.com
Fri Jul 1 09:52:33 PDT 2011


Ah, oh yes. I think I fail at mailing lists :3

2011/7/1 Peter Michaux <petermichaux at gmail.com>

> Did you mean to send this to es-discuss?
>
> Peter
>
> On 2011-07-01, at 8:51 AM, Quildreen Motta <quildreen at gmail.com> wrote:
>
> Actually, in my opinion, constructor functions add needless complexity on
> JavaScript's inheritance mechanism, and yes, they do shift the focus from
> prototypical inheritance -- using constructors feels much more like creating
> a layer of metadata to extend some behaviours, than extending objects.
>
> With constructors, you basically have the following:
>
> 1.) Want to extend Foo (an object).
> 2.) Create a function Bar, write initialisation code (even if you don't
> need one).
> 3.) Set Bar.prototype to an object that clones Foo.
> 4.) use new Bar to construct a new object that extends Foo (and does
> initialisation) -- which might return some other object.
> 5.) Extend the new Bar object as you see fit.
> 6.) Use the object.
>
> With prototypes you have the following:
>
> 1.) Want to extend Foo (an object).
> 2.) Create a new object that points to Foo.
> 3.) Extend this new object -- which you can do either manually or by
> calling an initialisation function on the object.
> 4.) Use the object.
>
> The thing is: by removing the additional constructor function you simplify
> it. I had a really hard time trying to wrap my head around constructors and
> how they play with prototypes, lots of people out there face the very same
> problem when trying to use the OOP mechanisms that JavaScript provides,
> since it *looks* like the classical pattern they're used to, but in reality
> it works mostly different.
>
> You still see code around that does:
>
> function Foo() { }
> Foo.prototype = { describe: function(){ return 'Foo' } }
>
> function Bar() { }
> Bar.prototype = new Foo
>
> Some people are simply not aware that Foo is not a class, but something
> that is used to group initialisation and inheritance, so it would be only
> natural(?) for them to think that way when trying to extend something. Some
> people also think that `prototype' is a magical property used for
> inheritance of anything.
>
> With PaC you solve those problems by making the mechanisms that JS uses for
> inheritance explicit. That is, if you want to extend Foo, you just extend
> Foo.
>
> 2011/6/30 Peter Michaux < <petermichaux at gmail.com>petermichaux at gmail.com>
>
>> On Thu, Jun 30, 2011 at 4:46 PM, Axel Rauschmayer < <axel at rauschma.de>
>> axel at rauschma.de> wrote:
>> > What problem have you solved by giving the prototype a name?
>>
>> The names I choose makes it clear to the reader that the prototype is
>> one element (zero) in a set of elements (complex numbers).
>>
>> A name gives a reference to the object that is not related to any
>> constructor function. Constructor functions are something separate
>> from the prototype object (zero).
>>
>>
>> > The proposal is
>> > not (just) about giving prototypes names.
>>
>> Understood but it seemed that the proposal started from the idea that
>> JavaScript needs to get back to its prototype roots. I don't think
>> JavaScript has ever been far from its prototype roots especially if
>> the programmer shifts to thinking about a prototype object instead of
>> thinking about a functions prototype property.
>>
>>
>> > Problems that both prototypes-as-classes (PAC) and class literals (CL)
>> are
>> > trying to solve are:
>> > - Subclassing is hard and not directly supported by the language:
>> connecting
>> > prototypes, chaining constructors, super-references.
>>
>> Object.getPrototypeOf(this).foo.call(this) is pretty long.
>>
>>
>> > - Class properties are not inherited
>>
>> Class property inheritance is definitely a secondary issue compared
>> with the instance objects themselves.
>>
>> > (CoffeeScript copies them “manually”).
>>
>> Which I think is unsatisfactory and has a lot of gotchas when some
>> properties are arrays and other properties have primitive values.
>>
>> --
>>
>> It seems to me that perhaps the PaC drifted too far or perhaps started
>> too far from what JavaScript has already. If the idea is to shift the
>> focus more towards prototypes, then starting from something like what
>> I've written and adding "super" syntax would be more consistent with
>> what JavaScript already has.
>>
>> Peter
>>
>>
>> > If none of these issues are involved then today’s constructor functions
>> are
>> > OK.
>> > Pros of each approach:
>> > (1) Pro CL: no need to support two kinds of classes: prototypes *and*
>> > constructor functions.
>> > (2) Pro PAC: look the same as class literals, but don’t need an extra
>> > translation step.
>> > (1) weighs heavily and will probably make it impossible to sell PAC to
>> TC39.
>> > There is the precedent of Python having two styles of classes [1] at the
>> > same time, but I don’t think they diverged as heavily as constructor
>> > functions and PAC.
>> > If you want to argue against PAC benefits, take a look at Sect. 3 here:
>> > <http://www.2ality.com/2011/06/prototypes-as-classes.html#3>
>> http://www.2ality.com/2011/06/prototypes-as-classes.html#3
>> > [1] <http://stackoverflow.com/questions/54867/old-style-and-new-style-classes-in-python>
>> http://stackoverflow.com/questions/54867/old-style-and-new-style-classes-in-python
>> > Axel
>> > On Jul 1, 2011, at 1:07 , <es-discuss-request at mozilla.org>
>> es-discuss-request at mozilla.org wrote:
>> >
>> > From: Peter Michaux < <petermichaux at gmail.com>petermichaux at gmail.com>
>> > Date: June 30, 2011 21:54:47 GMT+02:00
>> > To: es-discuss < <es-discuss at mozilla.org>es-discuss at mozilla.org>
>> > Subject: prototype focus
>> >
>> >
>> > There seems to have been a lot of fuss here about focusing on
>> > prototypes first rather than on constructor functions. As it stands
>> > now, I don't see how JavaScript makes focusing on prototypes
>> > difficult.
>> >
>> > // focus on the prototype first
>> > // Make it non-abstract.
>> > // Call it "zero" not "number".
>> > // (Another example: Call the object "adam" not "person".)
>> >
>> > var zero = {
>> >    realPart: 0,
>> >    imagPart: 0,
>> >    getMagnitude: function() {
>> >        return Math.sqrt(this.realPart * this.realPart +
>> >                         this.imagPart * this.imagPart);
>> >    }
>> > };
>> >
>> > // JavaScript makes it possible to have a variety of constructors
>> > // for objects that have zero as their prototype.
>> > // Yes the constructor property is gone. Is that actually a problem?
>> >
>> > function Real(r) {
>> >    this.realPart = r;
>> > }
>> > Real.prototype = zero;
>> >
>> > function Imaginary(i) {
>> >    this.imagPart = i;
>> > }
>> > Real.prototype = zero;
>> >
>> > function Complex(r, i) {
>> >    this.realPart = r;
>> >    this.imagPart = i;
>> > }
>> > Complex.prototype = zero;
>> >
>> > // Now make some objects.
>> >
>> > var two = new Real(2);
>> > var i = new Imaginary(2);
>> > var oneone = new Complex(1, 1);
>> >
>> > Isn't that prototype-focused enough?
>> >
>> > --
>> > Dr. Axel Rauschmayer
>> > <axel at rauschma.de>axel at rauschma.de
>> > <http://twitter.com/rauschma>twitter.com/rauschma
>> > home: <http://rauschma.de>rauschma.de
>> > blog: <http://2ality.com>2ality.com
>> >
>> >
>> >
>> _______________________________________________
>> es-discuss mailing list
>>  <es-discuss at mozilla.org>es-discuss at mozilla.org
>>  <https://mail.mozilla.org/listinfo/es-discuss>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110701/1d397492/attachment-0001.html>


More information about the es-discuss mailing list