prototype focus

Irakli Gozalishvili rfobic at gmail.com
Fri Jul 1 06:45:49 PDT 2011


Sorry I did not intended to send email yet:

So here is my points:

1. Does this looks familiar (version with syntax highlighting https://gist.github.com/1058534) 

function Foo(options) { .... }
Foo.prototype.do_foo_job = function() { ... }

function Bar(options) {
if (!(this instanceof Bar))
return this new Bar(options);
Foo.apply(this, arguments);
}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.do_bar_job = function() { .... };

With focus on prototypes it's as simple as this:
var Foo = Object.extend({
initialize: function(options) { ... },
do_foo_job: function() { ... }
})

var Bar = Foo.extend({
do_bar_job: function() { ... }
})

Why should not be I able to reuse initialization function, or why do I have to create constructor function for all classes / subclasses ?

2. With a constructor focused classes you end up maintaing two sets of properties: 1. prototype properties and 2. (java static like) constructor properties, which adds complexity requires dedicated syntax in declarative classes syntax.

3. It could be my personal, internal conflict, but I seriously can't see any reason for `constructor` to be a special among all other methods, by having privilege to hold a reference to a prototype object (I don't even mention that this reference is circular by default). Overall `prototype` property feels like hack to emulate Java like classes.

4. With focus on prototypes there is potential to further reduce language syntax (hopefully new, instanceof will die off) instead of cluttering even further. 

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


On Friday, 2011-07-01 at 15:19 , Irakli Gozalishvili wrote:

> I absolutely agree with Alex and have few other points:
> 
> 1. Does this code looks familiar ?
> 
> > function Foo(options) { .... }
> > Foo.prototype.do_foo_job = function() { ... }
> > 
> > function Bar(options) {
> > if (!(this instanceof Bar))
> >  return this new Bar(options);
> > Foo.apply(this, arguments);
> > }
> > Bar.prototype.do_bar_job = function() {
> >  ....
> > }
> > 
> 
> With focus on prototype this is so much simpler: 
> 
> 
> var Foo = Object.extend({
>  initialize: function(options) { ... },
> do_foo_job: function() { ... }
> })
> 
> 
> On Friday, 2011-07-01 at 11:10 , Axel Rauschmayer wrote:
> 
> > > 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.
> > 
> > That is basically the point that the proposal tries to make. Have you taken a look at the library code? It is very short and not a radical overhaul.
> > http://dl.2ality.com/dl/2011/06/Proto.js
> > 
> > Note how below, there is always an extra "prototype" in there with constructor functions.
> > 
> > Super-calls (there will be syntactic sugar for this):
> > - Constructor functions: Superclass.prototype.foo.call(this)
> > - PAC: Superclass.foo.call(this)
> > 
> > Subclassing:
> > - Constructor functions: Subclass.prototype = Object.create(Superclass.prototype)
> > - PAC: let Subclass = Object.create(Superclass)
> > 
> > Instanceof (internally):
> > - Constructor functions: o instanceof C === C.prototype.isPrototypeOf(o)
> > - PAC: o instanceof C === C.isPrototypeOf(o)
> > 
> > 
> > > > 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.
> > 
> > See above.
> > 
> > > 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.
> > 
> > 
> > “too far from what JavaScript has already” is very vague. How so? With class literals, your code will look like PAC, anyway. Have you taken a look at Sect. 3? Do you agree that the mentioned conceptual simplifications hold?
> > http://www.2ality.com/2011/06/prototypes-as-classes.html#3
> > 
> > I find Brendan’s anti-PAC argument much more convincing: that all people might find it more natural to think in terms of constructors than in terms of prototypes. If that is the case then PAC would be a bad idea. The other convincing anti-PAC argument is that it is a bad idea to have two class mechanisms.
> > 
> > -- 
> > Dr. Axel Rauschmayer
> > 
> > axel at rauschma.de (mailto:axel at rauschma.de)
> > twitter.com/rauschma (http://twitter.com/rauschma)
> > 
> > home: rauschma.de (http://rauschma.de)
> > blog: 2ality.com (http://2ality.com)
> > 
> > 
> > 
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
> > https://mail.mozilla.org/listinfo/es-discuss
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110701/733a973d/attachment-0001.html>


More information about the es-discuss mailing list