Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 8:36 PM, Axel Rauschmayer wrote:

> I’m not arguing in favor of prototypes-as-classes, just against the 
> assertion, below.

I think you missed my point. You can't call a prototype -- it's generally not 
callable. But in the PaC proposal you can 'new' it.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Axel Rauschmayer]

I’m not arguing in favor of prototypes-as-classes, just against the assertion, 
below.

> There has to be a constructor function somewhere, somehow. The issue is what 
> name you invoke it by when calling vs. constructing. With 
> constructor-as-class it's the same name, the name of the abstraction denotes 
> the constructor. With prototype-as-class, the two diverge -- you call 
> C.constructor but you 'new C' (although you can spell out 'new C.constructor' 
> too if you like).


let o = new X(...);
- Constructor functions: X is the name of the construct that initializes the 
instance. Implicit/hidden: Specifying the prototype.
- Prototypes-as-classes: X is the name of the prototype of the new instance. 
Implicit/hidden: Invoking the method constructor().

Both have merit, I don’t see either one as being more elegant.

Purely subjectively, I find that the prototype is the thing that stays and 
lasts, while initialization only happens once. Obviously, constructor fans 
disagree with this assertion.

But if you like class literals syntactically then maybe we’re not even 
disagreeing here. Their clear advantage (over PaCs) is that they desugar to 
something that is perfectly compatible with current semantics.

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 6:45 PM, Bob Nystrom wrote:

> On Tue, Jun 28, 2011 at 6:38 PM, Brendan Eich  wrote:
> It's true, classes want to slide down various lower slopes, over time. The 
> "lint brush" problem, I called it. We on TC39 are obligated to hold the line.
> 
> Have you seen this occur in practice? My impression from C++ and C# is that 
> most of the language addition over time was at the expression or statement 
> level and not so much in class bodies.

I meant JS classes. We have traits waiting in the wings. Trademarking/guards 
have designs on classes. Something else lurks, I forget at the moment.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Bob Nystrom]

On Tue, Jun 28, 2011 at 6:38 PM, Brendan Eich  wrote:

> It's true, classes want to slide down various lower slopes, over time. The
> "lint brush" problem, I called it. We on TC39 are obligated to hold the
> line.
>

Have you seen this occur in practice? My impression from C++ and C# is that
most of the language addition over time was at the expression or statement
level and not so much in class bodies.

- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 6:33 PM, Axel Rauschmayer wrote:

> Sorry for dragging this out. The following should be my last email in this 
> thread.

Axel, thanks for interacting, nothing to apologize for here.


>> The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, 
>> b) with extra rules for object return value, which is a complexity. 
>> Especially for abstractions that want to be callable without 'new' to 
>> construct a new instance (Array, e.g.).
> 
> That is complexity that is added to make things compatible with constructor 
> functions and current built-ins. If you have to factor that in, then it is 
> indeed hard to argue in favor of prototypes-as-classes.

There has to be a constructor function somewhere, somehow. The issue is what 
name you invoke it by when calling vs. constructing. With constructor-as-class 
it's the same name, the name of the abstraction denotes the constructor. With 
prototype-as-class, the two diverge -- you call C.constructor but you 'new C' 
(although you can spell out 'new C.constructor' too if you like).


> I don’t particularly like that most things are constructed via new, but that 
> in a few cases, you can omit the “new” if you want to. I’m also trying to 
> avoid the Array constructor (e.g. there is no way to create arrays such as 
> [3] with it).

I hate that particular misfeature of Array.


> But I do understand that that’s how it is, that people use it and that there 
> is nothing one can do about it.

The Array(length) botch aside, yes: many constructors are callable is functions 
and they construct in that case too.


> If I summarize my perceived advantages as follows, then it becomes clear that 
> they might not be worth the trouble of having two kinds of classes:
> 
> (1) Simpler instanceof (Contra: no need to look under the hood)
> (2) Simpler subclassing (Contra: not needed very often, super-references make 
> most of the advantages go away). Minor inconvenience: having to set up 
> C.prototype.constructor in the subclass.
> (3) Inheritance of class methods (Contra: I’ve only seen one case where this 
> mattered – an inheritance API with an extend() method. Contra: property name 
> pollution where constructors are currently used as namespaces).
> 
> Looking at these points, it becomes clear that with class literals as 
> syntactic sugar, we get all of the advantages of prototypes-as-classes, 
> without their disadvantage of having to support two kinds of classes. 
> However, class literals are still a move away from the constructor as the 
> dominant construct (conceptually, – nothing changes under the hood).

It's true, classes want to slide down various lower slopes, over time. The 
"lint brush" problem, I called it. We on TC39 are obligated to hold the line.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Axel Rauschmayer]

Sorry for dragging this out. The following should be my last email in this 
thread.

> The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, 
> b) with extra rules for object return value, which is a complexity. 
> Especially for abstractions that want to be callable without 'new' to 
> construct a new instance (Array, e.g.).

That is complexity that is added to make things compatible with constructor 
functions and current built-ins. If you have to factor that in, then it is 
indeed hard to argue in favor of prototypes-as-classes.

I don’t particularly like that most things are constructed via new, but that in 
a few cases, you can omit the “new” if you want to. I’m also trying to avoid 
the Array constructor (e.g. there is no way to create arrays such as [3] with 
it).

But I do understand that that’s how it is, that people use it and that there is 
nothing one can do about it.

If I summarize my perceived advantages as follows, then it becomes clear that 
they might not be worth the trouble of having two kinds of classes:

(1) Simpler instanceof (Contra: no need to look under the hood)
(2) Simpler subclassing (Contra: not needed very often, super-references make 
most of the advantages go away). Minor inconvenience: having to set up 
C.prototype.constructor in the subclass.
(3) Inheritance of class methods (Contra: I’ve only seen one case where this 
mattered – an inheritance API with an extend() method. Contra: property name 
pollution where constructors are currently used as namespaces).

Looking at these points, it becomes clear that with class literals as syntactic 
sugar, we get all of the advantages of prototypes-as-classes, without their 
disadvantage of having to support two kinds of classes. However, class literals 
are still a move away from the constructor as the dominant construct 
(conceptually, – nothing changes under the hood).

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 5:55 PM, Brendan Eich wrote:

> The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, 
> b) with extra rules for object return value, which is a complexity.

Sorry, that was unclear: I meant the indirection through .constructor was a 
complexity, not the substituted object return value which applies to both 
approaches.


> Especially for abstractions that want to be callable without 'new' to 
> construct a new instance (Array, e.g.).

This is a crucial case. User-defined functions can be new'ed or invoked without 
new. They have .prototypes. None of this is going away.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 5:45 PM, Axel Rauschmayer wrote:

>> But before you've created an instance, it is pretty handy to have the 
>> constructor bound to a name so you can get to it. I don't think making the 
>> named object be the constructor means that they're *more* important, just 
>> that you generally have to go through them *first* to get to an instance. 
>> They get the name because they're the entrypoint.
> 
> It depends on how you view instance creation:
> 
> Prototypes-as-classes: new C() means:

If there are arguments in between the ( and ), they are passed to o.constructor.

> (1) Create an instance o whose prototype is C.
> (2) Initialize the new instance via o.constructor().

What if o.constructor returns another object than o? See below


> Constructor functions: new C() means:
> (1) Create an instance o whose prototype is C.prototype.
> (2) Initialize it via the body of the constructor function (with |this| set 
> up properly).

Step (2) could be exactly the same as the previous step (2), modulo the 
forgotten feature which is needed in both cases:

For a function C in JS today, the return value if an object trumps the new 
instance (and engines actually avoid creating a new instance if it isn't needed 
for this reason). So there's more to it than this two-step procedure.


> 
> Thus:
> - Prototypes-as-classes: step (1) determines the name of the class (which – 
> to me – makes more sense for instanceof and subclassing)
> - Constructor functions: step (2) determines the name of the class.

I don't see how the step # determines the name of the class. That's backward.

Rather, the two different choices of value bound to the name of the abstraction 
(prototype vs. constructor) determine the steps.

The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a, b) 
with extra rules for object return value, which is a complexity. Especially for 
abstractions that want to be callable without 'new' to construct a new instance 
(Array, e.g.).

Intuitions vary. There's nothing magically simpler about either approach. The 
|this| binding for the constructor invocation can be done in exactly the same 
way in both cases, but you left out the return value substitution feature.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes (PaCs)

[Axel Rauschmayer]

>> But with PaCs you don’t have to deconstruct, there is no detour from the 
>> class to another construct.
> 
> I just wrote that with classes or today's constructor functions, no one has 
> to deconstruct, either.

Sorry, I meant there is nothing more going on behind the scenes. I remember 
when I first read about instanceof, I couldn’t figure out how that operator 
could connect an instance to its constructor (that was before I knew about the 
“constructor” property which could in principle be used for this purpose). Then 
I read how this operator was handled internally and everything made sense.

> On the other hand, having PaCs and classes/constructors is more complex than 
> just having one. And we do not get the choice of just having PaCs.

True!

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Axel Rauschmayer]

> But before you've created an instance, it is pretty handy to have the 
> constructor bound to a name so you can get to it. I don't think making the 
> named object be the constructor means that they're *more* important, just 
> that you generally have to go through them *first* to get to an instance. 
> They get the name because they're the entrypoint.

It depends on how you view instance creation:

Prototypes-as-classes: new C() means:
(1) Create an instance o whose prototype is C.
(2) Initialize the new instance via o.constructor().

Constructor functions: new C() means:
(1) Create an instance o whose prototype is C.prototype.
(2) Initialize it via the body of the constructor function (with |this| set up 
properly).

Thus:
- Prototypes-as-classes: step (1) determines the name of the class (which – to 
me – makes more sense for instanceof and subclassing)
- Constructor functions: step (2) determines the name of the class.

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Axel Rauschmayer]

> From: Brendan Eich 
> Date: June 29, 2011 2:29:21 GMT+02:00
> 
> But that may not suffice to get the cows off the classy path. It may just 
> complicate new and instanceof, with few users benefiting. I claim we can do 
> little to control the outcome in terms of adoption. The downrev browser 
> problem, plus the classical OOP patterning in many devs' brains, count more 
> than our exhortations.
> 
> Would it be a better world if JS had always named the prototype, wired up new 
> C to use C.constructor, etc.? Maybe. But that road was not taken, and that 
> makes all the difference.


Agreed, that does indeed weigh heavily.

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes (PaCs)

[Brendan Eich]

On Jun 28, 2011, at 5:30 PM, Axel Rauschmayer wrote:

>>> What do you do with constructors-as-classes to check the following?
>>>  o instanceof C
>>> You look for C.prototype in the prototype chain of o.
>> 
>> No, the JS engine does that!
>> 
>> I, or random classy-dynamic-language-experienced users, just do "o 
>> instanceof C", i.e., they ask "is o an instance of [constructed by] C"?
>> 
>> Not everyone mentally deconstructs operators into their more primitive 
>> semantics.
> 
> But with PaCs you don’t have to deconstruct, there is no detour from the 
> class to another construct.

I just wrote that with classes or today's constructor functions, no one has to 
deconstruct, either.

On the other hand, having PaCs and classes/constructors is more complex than 
just having one. And we do not get the choice of just having PaCs.


>> Especially if there's no prototype-chain hacking, just shallow classical 
>> inheritance via a solid library.
> 
> 
> Then we would have a Python-like abstraction on top of current facilities. 
> Which I don’t mind at all. But I’m worried about the abstraction leaking.

What leak? We want sugar for today's patterns. I think you keep assuming 
everyone thinks about prototypes not constructors, but that is not universally 
true -- far from it.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes (PaCs)

[Axel Rauschmayer]

>> What do you do with constructors-as-classes to check the following?
>>   o instanceof C
>> You look for C.prototype in the prototype chain of o.
> 
> No, the JS engine does that!
> 
> I, or random classy-dynamic-language-experienced users, just do "o instanceof 
> C", i.e., they ask "is o an instance of [constructed by] C"?
> 
> Not everyone mentally deconstructs operators into their more primitive 
> semantics.

But with PaCs you don’t have to deconstruct, there is no detour from the class 
to another construct.

> Especially if there's no prototype-chain hacking, just shallow classical 
> inheritance via a solid library.


Then we would have a Python-like abstraction on top of current facilities. 
Which I don’t mind at all. But I’m worried about the abstraction leaking.

If prototypes already make it all work in the background, why not try and make 
do just with them?

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 4:41 PM, Bob Nystrom wrote:

> From my view, JS-of-today is no less prototype-based than what Axel is 
> proposing, it just wires things up a bit differently. Or is there something 
> I'm missing?

Brendan here, you know, the idiot who perpetrated JS. You are not missing 
anything. I wired up functions as constructors with .prototype properties to 
mimic Java classes, and supported the new operator, from JS1.0 in 1995 on. I 
made JS prototypal but not Self-like (no copy message, no multiple parents, no 
prototypes-not-constructors).

So now that we've cleared this up ;-), can we agree that prototypes and 
closures rock, and that constructor functions are not going away?

If so, it seems to me the prototype-first idea is trying to roll a very large, 
still moving stone up a tall hill. Yes, you can use prototypes that way. Indeed 
nothing stops users of ES.next, assuming <| or whatever it'll be called, and 
super-in-object-initialisers, make it to the finish line.

But that may not suffice to get the cows off the classy path. It may just 
complicate new and instanceof, with few users benefiting. I claim we can do 
little to control the outcome in terms of adoption. The downrev browser 
problem, plus the classical OOP patterning in many devs' brains, count more 
than our exhortations.

Would it be a better world if JS had always named the prototype, wired up new C 
to use C.constructor, etc.? Maybe. But that road was not taken, and that makes 
all the difference.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Bob Nystrom]

On Tue, Jun 28, 2011 at 5:19 PM, Axel Rauschmayer  wrote:
As an aside:
- Static methods in Java always felt like a hack, because Java’s creators
couldn’t bring themselves to support first-class functions.
- Thus: I would much prefer to put Object.* methods into a module (once we
have those). The same holds for “class methods” such as Math.*. There Math
is used for namespacing and not really a class.

+1 for that.

> However: Prototypes are already *the* core mechanism with regard to JS
inheritance, they are what stays after an instance has been created, they
are actually used for instanceof tests, etc.

But before you've created an instance, it is pretty handy to have the
constructor bound to a name so you can get to it. I don't think making the
named object be the constructor means that they're *more* important, just
that you generally have to go through them *first* to get to an instance.
They get the name because they're the entrypoint.

   // Superclass
   var Person = {
   constructor: function (name) {
   this.name = name;
   },
   describe: function() {
   return "Person called "+this.name;
   }
   };

   // Subclass
   var Worker = Person <| {
   constructor: function (name, title) {
   Person.constructor.call(this, name);
   this.title = title;
   },
   describe: function () {
   return Person.describe.call(this)+" ("+this.title+")"; // (*)
   }
   };

For comparison's sake, here's that in the class proposal:

class Person {
  constructor(name) {
this.name = name;
  }
  describe() {
return "Person called " + this.name;
  }
}

class Worker extends Person {
  constructor(name, title) {
super(name);
this.title = title;
  }
  describe() {
return super.describe() + " (" + this.title + ")";
  }
}

I definitely sympathize with the purity/simplicity argument against adding
class syntax to JS, but for me, that code does read better with a dedicated
declarative class syntax.

- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript parser API

[David Herman]

Yeah, tough questions. I don't know. I tried to make the API flexible by 
allowing custom builders, and in fact if you look at the test suite you'll see 
I did a proof-of-concept showing how you could generate the format that Mark 
mentioned:


http://hg.mozilla.org/tracemonkey/file/2ce7546583ff/js/src/tests/js1_8_5/extensions/reflect-parse.js#l1051

But there are also tough questions about what the parser should do with 
engine-specific language extensions.

I agree about the issue of multiple parsers. The reason I was able to do the 
SpiderMonkey library fairly easily was that I simply reflect exactly the parser 
that exists. But to have a standards-compliant parser, we'd probably have to 
write a separate parser. That's definitely a tall order.

Dave

On Jun 28, 2011, at 4:02 PM, Mike Shaver wrote:

> On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer  wrote:
>> http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
>> 
>> I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance 
>> that this kind of API will make it into Harmony? It would be really useful 
>> for a variety of generative/meta-programming tasks.
> 
> I'm interested in this too, for a number of applications, but I keep
> getting stuck on one thing.
> 
> Would you standardize the resulting parse tree, too?  That would
> probably mean that every engine would have two parsers, since I'm sure
> we produce different parse trees right now, and wouldn't want to lock
> down our parser mechanics for all time.
> 
> If you don't standardize the parse tree, is it still useful?  More
> useful than just using narcissus or whatever other parsing libraries
> exist?
> 
> Mike
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

[Brendan Eich]

On Jun 28, 2011, at 4:35 PM, Breton Slivka wrote:

> Ooo that's exciting! And so, if I'm not being too presumptuous, Does
> this mean that constructions like if, while, etc become prefix
> operators that can invoke a block lambda?

There's no point redoing the built-in statements that way, and we cannot handle 
the "else" keyword or "while" in do-while loops without yet more magic. I don't 
think it's worth it, yet.


> I've been flat out and haven't been able to look at this so it''s
> exciting to see some progress on it. Just in case:
> I hereby relinquish all copyright, trademark and patent rights I may
> possibly hold, to the idea of "unifying the object literal and block
> grammar constructions" to the TC39 group and its constituent members,
> so help me god.

No worries. And note that I did not unify block with object literal so much as 
disambiguate them. But I think there's an LR(1) ambiguity (fixable) still. More 
in a bit.

/be

> -Breton Slivka
> 
> 
> On Wednesday, June 29, 2011, Brendan Eich  wrote:
>> On Jun 23, 2011, at 3:27 PM, Brendan Eich wrote:
>> Also, if any { block } could be a lambda, perhaps we won't need that (nor 
>> any new) syntax for block-lambdas.
>> We would need new syntax still, for formal parameters.
>> Making blocks be expressions requires unifying the ObjectLiteral and Block 
>> productions. I don't know how to do this in without at least two-token 
>> lookeahead, and it is not a backward compatible change if done for all 
>> places where Statement : Block in the current grammar.
>> Apologies for not crediting Breton Slivka, who suggested working this 
>> approach here:
>> https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html
>> Here's an attempt to formalize the unification grammatically.
>> Block:{ UnlabeledStatementFirstList }{ WellLabeledStatement 
>> StatementList? }
>> UnlabeledStatementFirstList:UnlabeledStatement
>> UnlabeledStatementFirstList Statement
>> Statement:UnlabeledStatementLabeledStatement
>> UnlabeledStatement:BlockVariableStatementEmptyStatement
>> ExpressionStatementContinueStatementReturnStatement
>> LabelUsingStatementDebuggerStatement
>> LabelUsingStatement:IfStatementIterationStatementBreakStatement  
>>   WithStatementSwitchStatementThrowStatementTryStatement
>> LabeledStatement:Identifier : Statement
>> WellLabeledStatement:Identifier : LabelUsingStatementIdentifier : 
>> WellLabeledStatement
>> (I'm using the American spelling of "labeled" and "unlabeled". Can't help 
>> myself!)
>> Notice the right recursion in WellLabeledStatement's rule.
>> The idea is to allow
>> javascript:42
>> and other such "not-well-labeled statements" for backward compatibility, but 
>> only at top level in SourceElement context. Not after a { that starts a 
>> Block.
>> After a { that starts a Block, you can have a label only if it is followed 
>> by a statement that could possibly use that label (labels may nest in such a 
>> WellLabeledStatement).
>> Any expression after a label that follows a { therefore must be the value 
>> part of a PropertyNameAndValueList in an ObjectLiteral.
>> This is a mostly-compatible change. Again props to crock for suggesting 
>> restrictions to label usage as a spark that kindled this fire.
>> If I have this right, then we could add a new production:
>> PrimaryExpression:Block
>> to allow blocks as expressions. We'd still need the [lookahead ∉ {{, 
>> function}] restriction in ExpressionStatement.
>> Making blocks be expressions allows us to treat them as zero-parameter 
>> block-lambdas: ({statements}) instead of the ugly ({|| statements}). The 
>> semantics would be the same as with a block-lambda: evaluation of the Block 
>> is deferred until it is called, typeof says "function", reformed completion 
>> value is implicit return value, etc. See:
>> http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
>> (I haven't unified the above with the block lambda revival grammar yet; one 
>> step at a time.)
>> Grammar nerds, please validate!
>> /be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Axel Rauschmayer]

As an aside:
- Static methods in Java always felt like a hack, because Java’s creators 
couldn’t bring themselves to support first-class functions.
- Thus: I would much prefer to put Object.* methods into a module (once we have 
those). The same holds for “class methods” such as Math.*. There Math is used 
for namespacing and not really a class.

> From my view, JS-of-today is no less prototype-based than what Axel is 
> proposing, it just wires things up a bit differently. Or is there something 
> I'm missing?


I agree. However: Prototypes are already *the* core mechanism with regard to JS 
inheritance, they are what stays after an instance has been created, they are 
actually used for instanceof tests, etc. PaCs put more emphasis on them, that’s 
all. I find they really shine when it comes to subclassing. You have to work 
harder with constructor functions (super-references will help a little, 
though). See code below. To me, the prototypes are at the core of what is 
happening in subclassing.

== Prototypes as classes ==

// Superclass
var Person = {
constructor: function (name) {
this.name = name;
},
describe: function() {
return "Person called "+this.name;
}
};

// Subclass
var Worker = Person <| {
constructor: function (name, title) {
Person.constructor.call(this, name);
this.title = title;
},
describe: function () {
return Person.describe.call(this)+" ("+this.title+")"; // (*)
}
};

== Constructor functions ==

// Superclass
function Person(name) {
this.name = name;
}
Person.prototype.describe = function() {
return "Person called "+this.name;
};

// Subclass
function Worker(name, title) {
Person.call(this, name);
this.title = title;
}
Worker.prototype = Person.prototype <| {
constructor: Worker,
describe: function() {
return Person.prototype.describe.call(this)+" ("+this.title+")";
}
};


-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es-discuss Digest, Vol 52, Issue 161

[Brendan Eich]

On Jun 28, 2011, at 4:22 PM, Axel Rauschmayer wrote:

>> Plus, the prototype is in some ways secondary. It's the less directly used 
>> object when one calls a constructor often, after populating the prototype. 
>> And if class methods come into the picture, the prototype is even more 
>> "backstage", an implementation detail.
> 
> 
> That seems to be a matter of taste: To me prototypes are the core of 
> JavaScript inheritance. The single construct that is used to handle both 
> instance-of and subclass-of. If you draw an object diagram, it is 
> constructors that move into the background and prototypes that remain.
> 
> What do you do with constructors-as-classes to check the following?
>o instanceof C
> You look for C.prototype in the prototype chain of o.

No, the JS engine does that!

I, or random classy-dynamic-language-experienced users, just do "o instanceof 
C", i.e., they ask "is o an instance of [constructed by] C"?

Not everyone mentally deconstructs operators into their more primitive 
semantics. Especially if there's no prototype-chain hacking, just shallow 
classical inheritance via a solid library.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript parser API

[Axel Rauschmayer]

Maybe we could start with an “official” separate JavaScript-only implementation?

On Jun 29, 2011, at 1:05 , Mark S. Miller wrote:

> Hi Axel, I'm glad you're asking the right question. To clarify for everyone, 
> "EcmaScript-Harmony" (or just "Harmony") names our agreed trajectory for the 
> language following ES5. We understand that the goals of this trajectory will 
> take several new editions to realize. "ES-next" is our working name for the 
> next edition along this trajectory, likely to be named "ES6".
> 
> So, not having need proposed or sanctioned prior to the May meeting cutoff 
> date, I'd say the chances of this making ii into ES-next are vanishingly 
> small. However, it is consistent with the overall goals for Harmony, so yes. 
> Just because it's not a candidate for ES-next is no reason to postponing 
> discussing it on es-discuss of course. I would very much like to see 
> something along these lines become standard in some later edition.
> 
> 
> On Tue, Jun 28, 2011 at 4:34 PM, Axel Rauschmayer  wrote:
> http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
> 
> I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance 
> that this kind of API will make it into Harmony? It would be really useful 
> for a variety of generative/meta-programming tasks.
> 
> Axel
> 
> --
> Dr. Axel Rauschmayer
> 
> a...@rauschma.de
> twitter.com/rauschma
> 
> home: rauschma.de
> blog: 2ality.com
> 
> 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
> Cheers,
> --MarkM

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes (PaCs)

[Axel Rauschmayer]

>> Explaining constructors-as-classes is really hard, explaining subclassing is 
>> even harder.
> 
> This really depends on the student's background and previous experience. It 
> is not universally true.

True, but it’s the experience I’ve had so far (explaining JS to friends). And 
there were no Selfers (I wouldn’t even consider myself one).

Do students who prefer constructors really understand and use prototypes 
properly?

What I usually see is something like this:

function C(x, y) {
return {
x: x,
y: y,
doSomething: function() { ... }
};
}

That is indeed easier to understand than PaCs. It only becomes complicated when 
you move shared data into the prototype. And when you subclass.

There might be enough other obstacles to prevent PaCs from happening, but: Is 
there a way to test whether constructors or PaCs are easier to understand for 
newbies? For example: Give a few JS newcomers a description of both PaCs and 
constructors and let them rate both proposals with regard to ease of 
understanding?

What would be the question to ask, e.g. after someone has read my blog post? 
“Which do you find easier to understand – constructors or 
prototypes-as-classes?”
Problem: Finding descriptions that don’t have bias.

At any rate, I really want to see Allen’s proposal (once it is finished).

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Bob Nystrom]

On Tue, Jun 28, 2011 at 3:56 PM, Allen Wirfs-Brock 
wrote:
(actually in the today's most widely used class-based languages (Java, C#,
C++) a "class" is no an object at all and don't have
properties/fields/polymorphic methods/etc.  they really are just a scoping
mechanism.  What you are saying is more typical of many dynamically typed
class-based languages).

Understood. That's why I used the vague "set of properties" to describe
static methods in class-based languages. A class may not be a first-class
object (and there may not be a metaclass for it) but it still has a set of
methods associated with it for some loose definition of "associated".

> The "two objects" you speak of is purely an artifact of how the
class-bassed approach works.  It is not a fundamental characteristic of all
OO languages.

I have two responses to that:

You're right that it's an artifact of how the class-based approach works,
but I look at that as a positive sign: that artifact represents the choice
of many popular languages (and lots of idiomatic JS code for that matter).
If the cow-path is that well-worn, it may be worth paving it, or at least
tossing a bit of gravel down.

But, more abstractly, I do think there are two fundamentally different
"objects" here. Some operations, conceptually, relate to a kind of object,
but don't relate to any specific instance of it. Others are specific to a
single instance.

We can lump those operations together (and hope they don't collide), but I'm
having trouble seeing why we'd want to.

> When it is useful to have s separate factory object for creating the
instances of a prototype-based abstractions, prototype-based languages
simply create another object to act as the factory. that object can have
private state, addiional public properties for accessing canonical
instances, etc.

I think the lesson from lots of languages (including JS) is that those
factory objects are pretty handy. Why move away from them?

> or you can say
> 0.parseInt("1234");
> or any other integer object that was conveniently available.

When I see code like:

somePoint.flipX();

That implies to me that flipX() uses somePoint's state in some significant
way. If it didn't, why is somePoint receiving the message and not some other
object? So when I see:

0.parseInt("345");

I feel like the code is misleading the reader. Why am I sending "parseInt"
to 0 if it doesn't have anything to do with it?

> If you didn't want the ability to parse to be a method of integers you
would just create a factory object:
> IntegerBuilder.parse("1234");
>
> Why is this worse than a "static method"?

Who said it was? Factory objects are swell. I just don't see why instances
should inherit from them. In some general sense, a point in space at (3, 2)
is not a point factory, it's a point. Why should it inherit from an object
that represents a point factory?

>>  function Point(x, y) {
>>this.x = x; this.y = y;
>>  }
>
> note that the above isn't a property of the constructor, it is the
constructor.

Heh, understood. I was referring to the stuff *after* that bit. :)

> In a consistent prototype based usage, the "zero" point would probably
actually be the prototypical point in which case you would access it simply
as Pointl

I do realize that, and for very simple types like (immutable) points, that
model works pretty well. I'm not sure what the prototypical image would look
like (Lena?), or what the prototypical mailing address is (123 Main
Street?).

> (I'm ignoring the fact the a point abstraction with mutable x and y fields
is probably not a very good design).

I wouldn't be too eager to ignore things like that. People using our
languages may not be the best designers but they still want to get their job
done. If prototypes-as-classes help, that's awesome, but if it's just a gun
that auto-aims for their feet we haven't done them any favors.

> But you could, that's what it means to be a prototype-based language.

Well, that's what it means to be a prototype-based language *and* follow a
certain inheritance pattern. I don't think I'm arguing against prototypes.
I'm just not sold on making the object bound to the class name be the
prototype of instances of that class.

>From my view, JS-of-today is no less prototype-based than what Axel is
proposing, it just wires things up a bit differently. Or is there something
I'm missing?

- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

[Breton Slivka]

Ooo that's exciting! And so, if I'm not being too presumptuous, Does
this mean that constructions like if, while, etc become prefix
operators that can invoke a block lambda?
I've been flat out and haven't been able to look at this so it''s
exciting to see some progress on it. Just in case:
I hereby relinquish all copyright, trademark and patent rights I may
possibly hold, to the idea of "unifying the object literal and block
grammar constructions" to the TC39 group and its constituent members,
so help me god.
-Breton Slivka


On Wednesday, June 29, 2011, Brendan Eich  wrote:
> On Jun 23, 2011, at 3:27 PM, Brendan Eich wrote:
> Also, if any { block } could be a lambda, perhaps we won't need that (nor any 
> new) syntax for block-lambdas.
> We would need new syntax still, for formal parameters.
> Making blocks be expressions requires unifying the ObjectLiteral and Block 
> productions. I don't know how to do this in without at least two-token 
> lookeahead, and it is not a backward compatible change if done for all places 
> where Statement : Block in the current grammar.
> Apologies for not crediting Breton Slivka, who suggested working this 
> approach here:
> https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html
> Here's an attempt to formalize the unification grammatically.
> Block:    { UnlabeledStatementFirstList }    { WellLabeledStatement 
> StatementList? }
> UnlabeledStatementFirstList:    UnlabeledStatement    
> UnlabeledStatementFirstList Statement
> Statement:    UnlabeledStatement    LabeledStatement
> UnlabeledStatement:    Block    VariableStatement    EmptyStatement    
> ExpressionStatement    ContinueStatement    ReturnStatement    
> LabelUsingStatement    DebuggerStatement
> LabelUsingStatement:    IfStatement    IterationStatement    BreakStatement   
>  WithStatement    SwitchStatement    ThrowStatement    TryStatement
> LabeledStatement:    Identifier : Statement
> WellLabeledStatement:    Identifier : LabelUsingStatement    Identifier : 
> WellLabeledStatement
> (I'm using the American spelling of "labeled" and "unlabeled". Can't help 
> myself!)
> Notice the right recursion in WellLabeledStatement's rule.
> The idea is to allow
>     javascript:42
> and other such "not-well-labeled statements" for backward compatibility, but 
> only at top level in SourceElement context. Not after a { that starts a Block.
> After a { that starts a Block, you can have a label only if it is followed by 
> a statement that could possibly use that label (labels may nest in such a 
> WellLabeledStatement).
> Any expression after a label that follows a { therefore must be the value 
> part of a PropertyNameAndValueList in an ObjectLiteral.
> This is a mostly-compatible change. Again props to crock for suggesting 
> restrictions to label usage as a spark that kindled this fire.
> If I have this right, then we could add a new production:
> PrimaryExpression:    Block
> to allow blocks as expressions. We'd still need the [lookahead ∉ {{, 
> function}] restriction in ExpressionStatement.
> Making blocks be expressions allows us to treat them as zero-parameter 
> block-lambdas: ({statements}) instead of the ugly ({|| statements}). The 
> semantics would be the same as with a block-lambda: evaluation of the Block 
> is deferred until it is called, typeof says "function", reformed completion 
> value is implicit return value, etc. See:
> http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
> (I haven't unified the above with the block lambda revival grammar yet; one 
> step at a time.)
> Grammar nerds, please validate!
> /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es-discuss Digest, Vol 52, Issue 161

[Axel Rauschmayer]

> Plus, the prototype is in some ways secondary. It's the less directly used 
> object when one calls a constructor often, after populating the prototype. 
> And if class methods come into the picture, the prototype is even more 
> "backstage", an implementation detail.


That seems to be a matter of taste: To me prototypes are the core of JavaScript 
inheritance. The single construct that is used to handle both instance-of and 
subclass-of. If you draw an object diagram, it is constructors that move into 
the background and prototypes that remain.

What do you do with constructors-as-classes to check the following?
o instanceof C
You look for C.prototype in the prototype chain of o.

Axel

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes (PaCs)

[Brendan Eich]

On Jun 28, 2011, at 4:12 PM, Axel Rauschmayer wrote:

> Explaining constructors-as-classes is really hard, explaining subclassing is 
> even harder.

This really depends on the student's background and previous experience. It is 
not universally true.


> I bet that in the coming year more new people are going to learn JavaScript 
> than everyone who knows it now. We have to plan for former group, not for the 
> latter.

You can't assume the newcomers have no experience with other classy languages, 
though. Many do, and PaCs are more confusing (few Self students out there).

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes (PaCs)

[Axel Rauschmayer]

> From: Bob Nystrom 
> Date: June 28, 2011 21:34:30 GMT+02:00
> Subject: Re: Summary: prototypes as classes


=== Class methods becoming instance methods ===

I agree: This one point is weirder with PaCs than with constructors. It would 
be great if global variables (as in “the global object”) wouldn’t have to be an 
instance of Object.

Two mitigating factors:
- This is how it already works in Java: Each instance can access all of the 
class methods.
- With PaCs, a subclass inherits all the superclass methods. That is something 
that e.g. CoffeeScript does manually, currently.

=== Target audience ===

I can accept compatibility with existing code as an argument in favor of 
constructors, but not that that’s what people are familiar with.

Explaining constructors-as-classes is really hard, explaining subclassing is 
even harder. PaCs bring significant simplifications in both areas. I don’t like 
the idea of having something that superficially looks simple (class literals as 
syntactic sugar for constructors-as-classes), but has the same old complexity 
under the hood.

I bet that in the coming year more new people are going to learn JavaScript 
than everyone who knows it now. We have to plan for former group, not for the 
latter.

=== Instantiation versus initialization ===

> Your proposal would allow that, I think. For example, starting from yours:
> 
>   // Superclass
>   var Person = {
>   constructor: function (name) {
>   this.name = name;
>   },
>   describe: function() {
>   return "Person called "+this.name;
>   }
>   };
> 
> I could do:
> 
>   var bob = new Person("Bob");
>   bob.constructor("Fred"); // I guess I'm Fred now.
> 
> Does the above seem strange to you too?

Note that your two lines work *exactly* the same with the following code (which 
is ES5 JavaScript):

function Person(name) {
this.name = name;
}
Person.prototype.describe = function() {
  return "Person called "+this.name;
};

I do agree that it is a bit strange that the constructor is just another 
method. In a way, PaCs separate two concerns (that are muddled with constructor 
functions – see subclassing):

- Instantiation: Creating a new instance
- Initialization: Setting up a new instance

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript parser API

[Mark S. Miller]

On Tue, Jun 28, 2011 at 5:02 PM, Mike Shaver  wrote:

> On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer 
> wrote:
> > http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
> >
> > I’ve just read D. Herman’s post on Firefox’s parser API. Is there any
> chance that this kind of API will make it into Harmony? It would be really
> useful for a variety of generative/meta-programming tasks.
>
> I'm interested in this too, for a number of applications, but I keep
> getting stuck on one thing.
>
> Would you standardize the resulting parse tree, too?


A resulting AST, yes. And the need to agree on an AST is part of why
previous proposals along these lines failed to achieve consensus. I continue
to like the ASTs we generate at <
http://es-lab.googlecode.com/svn/trunk/site/esparser/index.html>. YMMV. But
I would be in favor any AST format we could agree on.




>  That would
> probably mean that every engine would have two parsers, since I'm sure
> we produce different parse trees right now, and wouldn't want to lock
> down our parser mechanics for all time.
>
> If you don't standardize the parse tree, is it still useful?  More
> useful than just using narcissus or whatever other parsing libraries
> exist?
> 
>

The only option I can see for standardizing a parser but not an AST is to
standardize an (SAX-like) callback emitting parser. But this doesn't really
avoid any of the hard issues. The signature of each of these callbacks has
exactly the same design issues as the format of an AST.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript parser API

[Mark S. Miller]

Hi Axel, I'm glad you're asking the right question. To clarify for everyone,
"EcmaScript-Harmony" (or just "Harmony") names our agreed trajectory for the
language following ES5. We understand that the goals of this trajectory will
take several new editions to realize. "ES-next" is our working name for the
next edition along this trajectory, likely to be named "ES6".

So, not having need proposed or sanctioned prior to the May meeting cutoff
date, I'd say the chances of this making ii into ES-next are vanishingly
small. However, it is consistent with the overall goals for Harmony, so
yes. Just because it's not a candidate for ES-next is no reason to
postponing discussing it on es-discuss of course. I would very much like to
see something along these lines become standard in some later edition.


On Tue, Jun 28, 2011 at 4:34 PM, Axel Rauschmayer  wrote:

> http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
>
> I’ve just read D. Herman’s post on Firefox’s parser API. Is there any
> chance that this kind of API will make it into Harmony? It would be really
> useful for a variety of generative/meta-programming tasks.
>
> Axel
>
> --
> Dr. Axel Rauschmayer
>
> a...@rauschma.de
> twitter.com/rauschma
>
> home: rauschma.de
> blog: 2ality.com
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Mike Shaver]

On Tue, Jun 28, 2011 at 3:34 PM, Bob Nystrom  wrote:
> I like the simplicity of this, but I'm not crazy about how it merges two
> distinct objects into one. TodayJS (and most class-based languages) let you
> distinguish two things:
> 1. A set of properties relevant to the class itself.
> 2. A set of properties shared by each instance of the class.
> In a class-based language, #1 up there is "static" methods and fields. So
> when you do something like this in Java:
>   Integer.parseInt("1234");
> The "parseInt" method isn't a method that you can call on an integer, it's a
> method you call on the Integer class itself.

Actually, in Java, you can (or could, when last Java and I spoke) call
class methods on instances:
  Integer boxed = new Integer(5);
  boxed.parseInt(42);

That doesn't work well in JS, because obviously there's no prevention
of name collisions.

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript parser API

[Mike Shaver]

On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer  wrote:
> http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
>
> I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance 
> that this kind of API will make it into Harmony? It would be really useful 
> for a variety of generative/meta-programming tasks.

I'm interested in this too, for a number of applications, but I keep
getting stuck on one thing.

Would you standardize the resulting parse tree, too?  That would
probably mean that every engine would have two parsers, since I'm sure
we produce different parse trees right now, and wouldn't want to lock
down our parser mechanics for all time.

If you don't standardize the parse tree, is it still useful?  More
useful than just using narcissus or whatever other parsing libraries
exist?

Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Allen Wirfs-Brock]

On Jun 28, 2011, at 8:34 PM, Bob Nystrom wrote:

> I like the simplicity of this, but I'm not crazy about how it merges two 
> distinct objects into one. TodayJS (and most class-based languages) let you 
> distinguish two things:

(actually in the today's most widely used class-based languages (Java, C#, C++) 
a "class" is no an object at all and don't have properties/fields/polymorphic 
methods/etc.  they really are just a scoping mechanism.  What you are saying is 
more typical of many dynamically typed class-based languages).

Note that the goal of the prototype as classes proposals is not to turn JS into 
more of a class-based language.  Instead it was to solve the same problem that 
classes solve but in a manner that returns JavaScript closer to its original 
prototype-based roots.  This was covered in  the message that started the 
"Prototype as new new class declaration" thread 
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015135.html  It is 
probably worth while going back to review those first few messages to get a 
better chance of what this proposal is really about.

While both the class-based approach and the prototype-base approach allow you 
to describe an open ended set of similar objects via a named abstraction, the 
key difference is in what you name.  In the class based approach you name the 
object that is responsible for creating new instances (the constructor) of the 
set. In the prototype-based approach you name the prototypical instance of the 
set. 

The "two objects" you speak of is purely an artifact of how the class-bassed 
approach works.  It is not a fundamental characteristic of all OO languages.  

When it is useful to have s separate factory object for creating the instances 
of a prototype-based abstractions, prototype-based languages simply create 
another object to act as the factory. that object can have private state, 
addiional public properties for accessing canonical instances, etc. 

In https://mail.mozilla.org/pipermail/es-discuss/2011-June/015195.html  is 
examine how the self language addressed various situations where "static 
methods" might be used in a class-based langauges.


> 
> 1. A set of properties relevant to the class itself.
> 2. A set of properties shared by each instance of the class.
> 
> In a class-based language, #1 up there is "static" methods and fields. So 
> when you do something like this in Java:
> 
>   Integer.parseInt("1234");
> 
> The "parseInt" method isn't a method that you can call on an integer, it's a 
> method you call on the Integer class itself.

In self, you would likely do exactly the above.  Integer would be the name of 
the prototypical integer object and that object would have a method named 
parseInt.
You then can just say: 
   Integer.parseInt("1234");//actually in self you would say: Integer 
parseInt: '1234'.
or you can say
0.parseInt("1234");
or any other integer object that was conveniently available.

If you didn't want the ability to parse to be a method of integers you would 
just create a factory object:
IntegerBuilder.parse("1234");

Why is this worse than a "static method"?

> 
> In Javascript, those are properties on the constructor:
> 
>   function Point(x, y) {
> this.x = x; this.y = y;
>   }

note that the above isn't a property of the constructor, it is the constructor. 
 It actually is a property of the prototype.

> 
>   Point.zero = function() { return new Point(0, 0); }
> 
>   Point.zero(); // "static" method.

 It's all a mater of how you think of responsibilities.  In a consistent 
prototype based usage, the "zero" point would probably actually be the 
prototypical point in which case you would access it simply as Pointl 


> 
> The second set of properties are properties on ".prototype" in JS: Its
> 
>   Point.prototype.flipX = function() {
> this.x = -this.x;
>   }
> 
>   var p = new Point(1, 2);
>   p.flipX();
>   p.x // -1
> 
> To me, those two sets are utterly distinct. This code looks pretty strange:
> 
>   Point.flipX(); // What x?
The x of the prototypical point named Point.  As a prototypical point it has 
all the properties of any other point instance including an x and y property.
(I'm ignoring the fact the a point abstraction with mutable x and y fields is 
probably not a very good design).

In practice, you probably wouldn't call such a method on the prototype, so you 
wouldn't see the above at all.  But you could, that's what it means to be a 
prototype-based language.

> 
>   var p = new Point(1, 2);
>   p.zero(); // This works, but what does it have to do with 'p'?

probably as much as any other Point method that creates a new instance.  Since 
you probably really do want to have immutable points, that means most point 
methods:

  p.add(new Point(3,4)); //returns a new point with x=4, y=6
  p.zero();  //return a point with x=0,y=0

But, similar to above, in practice you probably would seldom actually see the 
latter. You would jus

JavaScript parser API

[Axel Rauschmayer]

http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/

I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance 
that this kind of API will make it into Harmony? It would be really useful for 
a variety of generative/meta-programming tasks.

Axel

-- 
Dr. Axel Rauschmayer

a...@rauschma.de
twitter.com/rauschma

home: rauschma.de
blog: 2ality.com



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Unifying Block and ObjectLiteral (was: Re: block-lambda revival)

[Brendan Eich]

On Jun 23, 2011, at 3:27 PM, Brendan Eich wrote:

>> Also, if any { block } could be a lambda, perhaps we won't need that (nor 
>> any new) syntax for block-lambdas.
> 
> We would need new syntax still, for formal parameters.
> 
> Making blocks be expressions requires unifying the ObjectLiteral and Block 
> productions. I don't know how to do this in without at least two-token 
> lookeahead, and it is not a backward compatible change if done for all places 
> where Statement : Block in the current grammar.

Apologies for not crediting Breton Slivka, who suggested working this approach 
here:

https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html

Here's an attempt to formalize the unification grammatically.

Block:
{ UnlabeledStatementFirstList }
{ WellLabeledStatement StatementList? }

UnlabeledStatementFirstList:
UnlabeledStatement
UnlabeledStatementFirstList Statement

Statement:
UnlabeledStatement
LabeledStatement

UnlabeledStatement:
Block
VariableStatement
EmptyStatement
ExpressionStatement
ContinueStatement
ReturnStatement
LabelUsingStatement
DebuggerStatement

LabelUsingStatement:
IfStatement
IterationStatement
BreakStatement
WithStatement
SwitchStatement
ThrowStatement
TryStatement

LabeledStatement:
Identifier : Statement

WellLabeledStatement:
Identifier : LabelUsingStatement
Identifier : WellLabeledStatement

(I'm using the American spelling of "labeled" and "unlabeled". Can't help 
myself!)

Notice the right recursion in WellLabeledStatement's rule.

The idea is to allow

javascript:42

and other such "not-well-labeled statements" for backward compatibility, but 
only at top level in SourceElement context. Not after a { that starts a Block.

After a { that starts a Block, you can have a label only if it is followed by a 
statement that could possibly use that label (labels may nest in such a 
WellLabeledStatement).

Any expression after a label that follows a { therefore must be the value part 
of a PropertyNameAndValueList in an ObjectLiteral.

This is a mostly-compatible change. Again props to crock for suggesting 
restrictions to label usage as a spark that kindled this fire.

If I have this right, then we could add a new production:

PrimaryExpression:
Block

to allow blocks as expressions. We'd still need the [lookahead ∉ {{, function}] 
restriction in ExpressionStatement.

Making blocks be expressions allows us to treat them as zero-parameter 
block-lambdas: ({statements}) instead of the ugly ({|| statements}). The 
semantics would be the same as with a block-lambda: evaluation of the Block is 
deferred until it is called, typeof says "function", reformed completion value 
is implicit return value, etc. See:

http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival

(I haven't unified the above with the block lambda revival grammar yet; one 
step at a time.)

Grammar nerds, please validate!

/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Brendan Eich]

On Jun 28, 2011, at 12:34 PM, Bob Nystrom wrote:

> I like the simplicity of this, but I'm not crazy about how it merges two 
> distinct objects into one. TodayJS (and most class-based languages) let you 
> distinguish two things:
> 
> 1. A set of properties relevant to the class itself.
> 2. A set of properties shared by each instance of the class.

Yes, and I don't see a good solution to this.

From the point of view of utmost simplicity, ignoring history of other 
languages and of JS itself (not only the built-ins, the DOM and other host 
object APIs, and user-defined constructor functions), deferring classes wins.

But we can't ignore either tradition or user mental models still fostered by 
function-as-constructor-with-.prototype in JS, which is not going away. The Q&A 
at

http://www.quora.com/How-was-classical-inheritance-*supposed*-to-be-done-in-ECMAScript-3

shows how classical inheritance with class as constructor or factory for 
instances, not as prototype, has deep roots in developers' minds.

Plus, the prototype is in some ways secondary. It's the less directly used 
object when one calls a constructor often, after populating the prototype. And 
if class methods come into the picture, the prototype is even more "backstage", 
an implementation detail.


> In a class-based language, #1 up there is "static" methods and fields. So 
> when you do something like this in Java:
> 
>   Integer.parseInt("1234");
> 
> The "parseInt" method isn't a method that you can call on an integer, it's a 
> method you call on the Integer class itself.

Or perhaps a constructor, if not *the* constructor.

Irakli's Ruby-ish .new protocol could help unify how one constructors built-ins 
and new prototype-first abstractions, but it is not yet proposed, and it is a 
new protocol (no pun intended). Do we need a second constructor protocol?


> Your proposal would allow that, I think. For example, starting from yours:
> 
>   // Superclass
>   var Person = {
>   constructor: function (name) {
>   this.name = name;
>   },
>   describe: function() {
>   return "Person called "+this.name;
>   }
>   };
> 
> I could do:
> 
>   var bob = new Person("Bob");
>   bob.constructor("Fred"); // I guess I'm Fred now.
> 
> Does the above seem strange to you too?

It seems a bit strange to me. One can get used to many things. Probably people 
could get used to this, but the fact is JS developers are already "used to" 
constructors with prototypes, where the abstraction's name denotes the 
constructor, not the prototype.

Whatever I personally think, I suspect developers in general, and TC39 in 
particular, will be divided on this. We can find out the hard way, but I'm 
pretty sure we won't defer classes in favor of prototypes-first with 
.constructor as the more backstage object.

Grass roots spokes-models also tell me some grumbling against the <| operator 
hurts this class-free idea. And I note in the font I just used, the | is too 
tall compared to the <, an aesthetic bad omen.

/be

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Summary: prototypes as classes

[Bob Nystrom]

I like the simplicity of this, but I'm not crazy about how it merges two
distinct objects into one. TodayJS (and most class-based languages) let you
distinguish two things:

1. A set of properties relevant to the class itself.
2. A set of properties shared by each instance of the class.

In a class-based language, #1 up there is "static" methods and fields. So
when you do something like this in Java:

  Integer.parseInt("1234");

The "parseInt" method isn't a method that you can call on an integer, it's a
method you call on the Integer class itself.

In Javascript, those are properties on the constructor:

  function Point(x, y) {
this.x = x; this.y = y;
  }

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

  Point.zero(); // "static" method.

The second set of properties are properties on ".prototype" in JS:

  Point.prototype.flipX = function() {
this.x = -this.x;
  }

  var p = new Point(1, 2);
  p.flipX();
  p.x // -1

To me, those two sets are utterly distinct. This code looks pretty strange:

  Point.flipX(); // What x?

  var p = new Point(1, 2);
  p.zero(); // This works, but what does it have to do with 'p'?

Your proposal would allow that, I think. For example, starting from yours:

  // Superclass
  var Person = {
  constructor: function (name) {
  this.name = name;
  },
  describe: function() {
  return "Person called "+this.name;
  }
  };

I could do:

  var bob = new Person("Bob");
  bob.constructor("Fred"); // I guess I'm Fred now.

Does the above seem strange to you too?

- bob

On Sat, Jun 25, 2011 at 1:11 PM, Axel Rauschmayer  wrote:

> FWIW: I’ve written down my current understanding.
>
> http://www.2ality.com/2011/06/prototypes-as-classes.html
>
> --
> Dr. Axel Rauschmayer
>
> a...@rauschma.de
> twitter.com/rauschma
>
> home: rauschma.de
> blog: 2ality.com
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Bug in 10.5 (Declaration Binding Instantiation)?

[Andreas Rossberg]

Is it too late to incorporate errata for 5.1 already? :)

It seems that the algorithm specified in 10.5 is wrong. In order to
make sense, and match the informal description at the beginning of
Section 10.6, step 8 needs to take place before step 6. (Noticed by
Steven Keuchel.)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: minimal classes

[Allen Wirfs-Brock]

Dave,

I agree with your goal of simplifying things in this area.  In that regard, I 
think you bare-miniumn requirements align quite nicely with "prototypes as 
classes" as has been recently discussed here.  In case you haven't followed all 
the twists of the discussion, Axel Rauschmayer has a nice overview at 
http://www.2ality.com/2011/06/prototypes-as-classes.html . The big hangup with 
this approach until recently was that it did not seem to  fit well with the 
existing built-ins or constructor patterns.  However, it now appears that there 
is a pretty nice way to integrate the two approaches.

Taking this approach, we would have the full expressiveness of your 
bare-miniumn classes but achieve it using object literal extensions.   There is 
no need to add a new class declaration form. We would have something that works 
and feels like classes but which also preserves the prototypal inheritance 
focus and feel of ES.  It also continues to reserve the "class" keyword for 
future use, if it turns out that this simpler "prototype as classes" approach 
is inadequate (I don't think this will happen, but it is good to still have a 
fallback).

As soon as a get a block of time later this week I will write up a "prototype 
as classes" proposal that covers al the technical edge cases including 
integration with existing built-ins.

Allen 




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss