Re: More thoughts on Allen’s class definition pattern
On Oct 30, 2011, at 5:55 PM, Axel Rauschmayer wrote:
The only thing I find off the mark is the typography of |. In light of
this, and of the anti-grawlix reaction among many people, could we revisit
an infix operator used in restricted productions with [no LineTerminator
here] on the left of the operator contextual keyword?
I hope this is not just in deference to a few vocal opponents.
That's not the way to approach this. You could be among the few vocal
*pro*ponents of | -- do we need a statistically significant and valid survey?
There are plenty of fonts in which the triangle appearance is ugly or lost.
There are people who object independent of fonts to JS growing line-noise hair
at its advanced age. These are both worth considering. They can't be dismissed
with few and vocal.
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object), or my current best shot: 'beget'.
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
How about subsumes (as the inverse of “extends”)?
let obj = base subsumes {a: 1, b: 2}
let arr = base subsumes [p, q, r]
let fun = base subsumes function (...args) { ... }
let re = base subsumes /(\w+)\s+(\w)+/g
That doesn't work in two ways:
1. proto-linking is not subsumption in any set theoretic or dictionary (To
have as a part) sense. base does not have as a part the literal on the right.
Rather, proto-linking is JS's differential inheritance solution.
2. subsumes is too long and novel. beget has history thanks to Crock. We
could even have an Object.beget as the easy-to-use Object.create analogue -- it
would have to copy its second parameter in general (it couldn't restrict the
second parameter to be passed as a literal).
/be
A bit long, but reads nicely.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 30, 2011, at 6:19 PM, Axel Rauschmayer wrote:
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
It's still idiomatic as a name for differential inheritance, but it is more
pithy than 'make' or 'create' (and one character shorter than 'create' --
no Unix 'creat' reruns! ;-). Comments?
Of the various keywords that I been suggested for this operator, I think I
like it the best. It is probably good that it is fairly unique and
idiomatic.
Saying or writing triangle does not convey meaning, and it's confusing in
geometry/graphics contexts.
yes, my original suggest is that | should be produced prototype for
One last idea, then I’ll stop my bikeshedding:
I think it helps if it reads well. For example:
const Employee = Person refinedBy { ... }
const Employee = Person subsuming { ... }
const Employee = Person parenting { ... }
const Employee = Person above { ... }
const Employee = Person before { ... }
Sorry, these are ghastly (it's almost Halloween, but c'mon).
I searched a bit and re-read Smalltalk, Self, Cecil, and Io docs to get a
handle on what | does. It is not 'clone'. It ain't 'create' except in a
vacuous sense that's also already taken by ES5 Object.create. It isn't
subsuming in my view. refinedBy is closer but you'll get camelCaps keywords
into JS over my dead body!
I landed on 'beget' because 'create' is close but vague yet poisoned, and we
need something pithy. Doug already employed it ages ago. Is there a reason you
don't like 'beget'?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On 30/10/2011, at 23:36, Brendan Eich wrote:
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it names the initialization method
constructor in order to tie into the object construction mechanisms that
already exist in JS.
+1
The only thing I find off the mark is the typography of |. In light of this,
and of the anti-grawlix reaction among many people, could we revisit an infix
operator used in restricted productions with [no LineTerminator here] on the
left of the operator contextual keyword?
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object), or my current best shot: 'beget'.
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
It's still idiomatic as a name for differential inheritance, but it is more
pithy than 'make' or 'create' (and one character shorter than 'create' -- no
Unix 'creat' reruns! ;-). Comments?
Saying or writing triangle does not convey meaning, and it's confusing in
geometry/graphics contexts.
Perhaps a long arrow may work ?
let object= base == {a: 1, b: 2};
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
Does not overcome the grawlix objection.
/be
On Oct 31, 2011, at 12:20 AM, Jorge wrote:
On 30/10/2011, at 23:36, Brendan Eich wrote:
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it names the initialization method
constructor in order to tie into the object construction mechanisms that
already exist in JS.
+1
The only thing I find off the mark is the typography of |. In light of
this, and of the anti-grawlix reaction among many people, could we revisit
an infix operator used in restricted productions with [no LineTerminator
here] on the left of the operator contextual keyword?
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object), or my current best shot: 'beget'.
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
It's still idiomatic as a name for differential inheritance, but it is more
pithy than 'make' or 'create' (and one character shorter than 'create' -- no
Unix 'creat' reruns! ;-). Comments?
Saying or writing triangle does not convey meaning, and it's confusing in
geometry/graphics contexts.
Perhaps a long arrow may work ?
let object= base == {a: 1, b: 2};
--
Jorge.
___
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: More thoughts on Allen's class definition pattern
The only thing I find off the mark is the typography of |. In light of this, and of the anti-grawlix reaction among many people, could we revisit an infix operator used in restricted productions with [no LineTerminator here] on the left of the operator contextual keyword? Am I the only one who flinches when someone mentions adding another [no LineTerminator here]? Apart from adding to ASI fun (the less of which, the better), these suggestions are phrases, to be written in a certain layout. That is different from infix operators, and even infix operators are not as flexible as I'd like in JS (can't easily pass them as parameters, for a start). To balance the 'anti-grawlix' slogan, perhaps we should try to coin a counter-meme. How about 'cobol.js' for English-like infix operator phrases that aren't really infix operators, and aren't really English. As observed by Wadler, syntax details draw the most replies in language design discussions http://lambda-the-ultimate.org/node/4287 So, much as I'd like to, I'll not express my preferences on the syntax here. Instead, I'd like to call attention to some of the semantic, pragmatic, and organizational aspects that are still troubling me: - there are several parts of code that would be awkward to abstract over (restriction to object literals, infix operators), or make it difficult to use the new features in expression- oriented styles (in-place modification); these surface issues are pointing to deeper language design issues that have not been tackled yet (object cloning/copying, user-defined infix operators and conversion between infix operators and prefix functions) - infix operators fall into that hole of macros-later, value proxies later, no user-defined infix ops; it is interesting how much time is spent on specific infix operator questions here, given that some committee members were opposed to a general solution - the only argument against generalizing from object literals and avoiding in-place update was that cloning/ copying would be non-trivial to get right; but that non-triviality seems to me a very good reason why the language standard should have something to say about the topic; it comes up in several contexts; if you don't want to commit to deep or shallow or whatever forms of cloning/copying yet, how about defining the several possible forms, and providing operators/functions for them? Btw: several of my messages have not yet appeared on es-discuss, and es-discuss-owner is unresponsive. Claus http://clausreinke.github.com/ http://clausreinke.github.com/js-tools/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
Le 30/10/2011 23:36, Brendan Eich a écrit :
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it names the initialization method
constructor in order to tie into the object construction mechanisms that
already exist in JS.
+1
The only thing I find off the mark is the typography of |. In light of this,
and of the anti-grawlix reaction among many people, could we revisit an infix
operator used in restricted productions with [no LineTerminator here] on the
left of the operator contextual keyword?
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object)
What about 'protoOf'? Operators are not camelcase ('typeof',
'instanceof'). Maybe 'protoof', but since 'proto' ends in 'o', it
doesn't look very good to me (though I'm nit an native English speaker)
let o = base protoof {a:1, b:2};
let a = base protoof [1, 2, 3];
Or,
let o = base protoOf {a:1, b:2};
let a = base protoOf [1, 2, 3];
?
I would have suggested 'prototypeof' in reference to
Object.getPrototypeOf, but I find it a bit long.
Ideas?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
I think it helps if it reads well. For example:
const Employee = Person refinedBy { ... }
const Employee = Person subsuming { ... }
const Employee = Person parenting { ... }
const Employee = Person above { ... }
const Employee = Person before { ... }
Sorry, these are ghastly (it's almost Halloween, but c'mon).
I searched a bit and re-read Smalltalk, Self, Cecil, and Io docs to get a
handle on what | does. It is not 'clone'. It ain't 'create' except in a
vacuous sense that's also already taken by ES5 Object.create. It isn't
subsuming in my view. refinedBy is closer but you'll get camelCaps
keywords into JS over my dead body!
const Employee = Person refinedby { ... }
const Employee = Person refby { ... }
const Employee = Person by { ... }
(Precedence: instanceof)
I landed on 'beget' because 'create' is close but vague yet poisoned, and we
need something pithy. Doug already employed it ages ago. Is there a reason
you don't like 'beget'?
Only one: It does not read like English (unless you read it like a command).
How about:
const Employee = Person begets {}
But I will be so glad to have this operator, I don’t mind too much about the
actual name. I wouldn’t rule out proto, yet, though. To be read as “is
prototype of”.
I’m surprised that the anti-Grawlix faction is so passionate – using a like
operator for inheritance has a long tradition in theoretical computer science.
Adding a non-grawlix name to Object is a good argument against something
grawlixy, though.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
Le 31/10/2011 07:20, Brendan Eich a écrit :
On Oct 30, 2011, at 11:11 PM, Brendan Eich wrote:
It ain't 'create' except in a vacuous sense that's also already taken by
ES5 Object.create. It isn't subsuming in my view. refinedBy is closer
but you'll get camelCaps keywords into JS over my dead body!
I landed on 'beget' because 'create' is close but vague yet poisoned, and we
need something pithy. Doug already employed it ages ago. Is there a reason
you don't like 'beget'?
Also, 'beget' does match the sire or hatch connotation of taking a parent
(Self again) object and differentialy inheriting another object from it via
proto-linking. Clone means make a twin and mutate. Copy is, well, just a copy
-- arguably close to clone and one char shorter (so Self chose well). What we
have with | is more like generate a child -- hence, 'beget'.
Asking Google for beget:
---
Verb:
(typically of a man, sometimes of a man and a woman) Bring (a child)
into existence by the process of reproduction.
Give rise to; bring about.
Synonyms:
generate - breed - procreate - engender - father
---
It sounds indeed very much what you mean. I had to look up, because I,
as a non-native English speaker had never come across the word beget.
I had seen some JS libraries which used that word (which I thought was
specific to the library).
I think it would be interested to know what other non-native English
speaker think of beget. While operators like typeof or instanceof
have a pretty straightforward meaning, beget sounds more difficult to
grasp for non-native speakers, even those who are familiar with
programming (I had decent experience in C, C++, Java and Lisp before
starting with JavaScript).
beget sounds very much like what we want, but I just wanted to raise a
point about understanding and adoption, especially for the language of
the web.
Allen:
my original suggest is that | should be produced prototype for
What about 'protofor'?
let obj = base protofor {a: 1, b: 2}
let arr = base protofor [p, q, r]
let fun = base protofor function (...args) { ... }
let re = base protofor /(\w+)\s+(\w)+/g
Once again, for the specific case of functions, the proto operator has a
semantics that goes way beyond setting the [[prototype]] internal
property. Maybe 'protofor' for the [[prototype]] and 'beget' for the
constructor-related semantics?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
I searched a bit and re-read Smalltalk, Self, Cecil, and Io docs to get a
handle on what | does. It is not 'clone'.
It's not 'copy' (Self) either, clearly.
It ain't 'create' except in a vacuous sense that's also already taken by
ES5 Object.create. It isn't subsuming in my view. refinedBy is closer
but you'll get camelCaps keywords into JS over my dead body!
I landed on 'beget' because 'create' is close but vague yet poisoned, and we
need something pithy.
Also, 'beget' does match the sire or hatch connotation of taking a parent
(Self again) object and differentialy inheriting another object from it via
proto-linking. Clone means make a twin and mutate. Copy is, well, just a copy
-- arguably close to clone and one char shorter (so Self chose well). What we
have with | is more like generate a child -- hence, 'beget'.
Two more ideas:
const Employee = Person to { ... } // or any other preposition (prepositions
are like operators)
const Employee = Person parents { ... }
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
I still think | is more straight-forward to grasp to non-native speakers
-- they're likely to have stumbled upon that on UML classes, methinks.
Also, there's the problem of creating new reserved words in the languages,
imho it makes a language feel heavier and clunkier. I think one of the
greatest point of ECMAScript is that, despite the awful amount of reserved
words, the language still manages to be simple and straight forward for
people to grasp, except for a few semantic quirks here and there.
I don't think that evolution and simplicity have to be mutually exclusive.
Languages should strive to hide the perceived complexity from the end-user,
while still managing to be expressive. If we decide on using a keyword for
expressing |, this word should be as straight-forward and simple to grasp
for both native english-speaking people and non-native english-speaking
people, which I don't think any of the proposed words are =/
2011/10/31 Axel Rauschmayer a...@rauschma.de
I searched a bit and re-read Smalltalk, Self, Cecil, and Io docs to get
a handle on what | does. It is not 'clone'.
It's not 'copy' (Self) either, clearly.
It ain't 'create' except in a vacuous sense that's also already taken
by ES5 Object.create. It isn't subsuming in my view. refinedBy is
closer but you'll get camelCaps keywords into JS over my dead body!
I landed on 'beget' because 'create' is close but vague yet poisoned,
and we need something pithy.
Also, 'beget' does match the sire or hatch connotation of taking a
parent (Self again) object and differentialy inheriting another object from
it via proto-linking. Clone means make a twin and mutate. Copy is, well,
just a copy -- arguably close to clone and one char shorter (so Self chose
well). What we have with | is more like generate a child -- hence,
'beget'.
Two more ideas:
const Employee = Person to { ... } // or any other preposition
(prepositions are like operators)
const Employee = Person parents { ... }
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
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
Re: More thoughts on Allen’s class definition pattern
beget sounds very much like what we want, but I just wanted to raise a
point about understanding and adoption, especially for the language of
the web.
I wouldn’t worry, all of a programming language is new vocabulary, anyway. You
always have to learn semantics, so learning a new word (especially one that
increases your English vocabulary) shouldn’t be a problem. My worry is more
that it doesn’t read like a sentence. I would prefer
const Employee = Person begets { ... };
I think Java got it right with extends:
class Employee extends Person { ... }
What about 'protofor'?
let obj = base protofor {a: 1, b: 2}
let arr = base protofor [p, q, r]
let fun = base protofor function (...args) { ... }
let re = base protofor /(\w+)\s+(\w)+/g
Once again, for the specific case of functions, the proto operator has a
semantics that goes way beyond setting the [[prototype]] internal
property. Maybe 'protofor' for the [[prototype]] and 'beget' for the
constructor-related semantics?
Even though it contradicts my previous rules, I still tremendously like
“proto”: It does not create new vocabulary and has an operator-y feel to it.
let obj = base proto {a: 1, b: 2}
let arr = base proto [p, q, r]
let fun = base proto function (...args) { ... }
let re = base proto /(\w+)\s+(\w)+/g
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
begets is pure win. http://i.word.com/idictionary/beget, it's pronounceable
and searchable/google-able (being able to find new syntax docs is crucial). It
has a known history and follows an existing grammar precedent.
Perhaps least importantly, I feel like a can get excited about begets
/Rick
On Oct 31, 2011, at 2:11 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 30, 2011, at 6:19 PM, Axel Rauschmayer wrote:
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
It's still idiomatic as a name for differential inheritance, but it is
more pithy than 'make' or 'create' (and one character shorter than
'create' -- no Unix 'creat' reruns! ;-). Comments?
Of the various keywords that I been suggested for this operator, I think I
like it the best. It is probably good that it is fairly unique and
idiomatic.
Saying or writing triangle does not convey meaning, and it's confusing
in geometry/graphics contexts.
yes, my original suggest is that | should be produced prototype for
One last idea, then I’ll stop my bikeshedding:
I think it helps if it reads well. For example:
const Employee = Person refinedBy { ... }
const Employee = Person subsuming { ... }
const Employee = Person parenting { ... }
const Employee = Person above { ... }
const Employee = Person before { ... }
Sorry, these are ghastly (it's almost Halloween, but c'mon).
I searched a bit and re-read Smalltalk, Self, Cecil, and Io docs to get a
handle on what | does. It is not 'clone'. It ain't 'create' except in a
vacuous sense that's also already taken by ES5 Object.create. It isn't
subsuming in my view. refinedBy is closer but you'll get camelCaps
keywords into JS over my dead body!
I landed on 'beget' because 'create' is close but vague yet poisoned, and we
need something pithy. Doug already employed it ages ago. Is there a reason
you don't like 'beget'?
/be
___
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: More thoughts on Allen’s class definition pattern
begets is pure win. http://i.word.com/idictionary/beget, it's pronounceable
and searchable/google-able (being able to find new syntax docs is crucial).
It has a known history and follows an existing grammar precedent.
Perhaps least importantly, I feel like a can get excited about begets
let obj = base begets {a: 1, b: 2}
let arr = base begets [p, q, r]
let fun = base begets function (...args) { ... }
let re = base begets /(\w+)\s+(\w)+/g
let Employee = Person begets { ... }
Three positive aspects of begets:
- begets (as opposed to “beget”) in the above examples reads like English.
- We have created a handy new word for talking about prototypal inheritance: a
prototype begets an object, an object is begotten (sic?) by its prototype.
- It works the same for “subclassing” and for creating instances (singleton
instances, otherwise, you would use “new”).
If people manage to get over their class bias (which is hard, because we have
been exposed to classes so much) then “begets” is a much more natural way of
doing things, because you always directly work with and connect objects.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 30, 2011, at 11:20 PM, Brendan Eich wrote: I landed on 'beget' because 'create' is close but vague yet poisoned, and we need something pithy. Also, 'beget' does match the sire or hatch connotation of taking a parent (Self again) object and differentialy inheriting another object from it via proto-linking. Clone means make a twin and mutate. Copy is, well, just a copy -- arguably close to clone and one char shorter (so Self chose well). What we have with | is more like generate a child -- hence, 'beget'. I've (very) briefly considered sires as it has the right connotation. some others (probably all too long for Brendan's tastes): provides (properties for) provisions generalizes derives spawns engenders differentiates spawn (bad concurrency connotations) parent (bad DOM connotations) Not accurately descriptive but close enough that they have some of the right connotations. build devise forge form invest Note that for many non-native English speakers probably don't have many of these words (including beget) in their vocabularies. For them, a symbolic token such as | or : is probably just as meaningful. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 5:45 AM, Axel Rauschmayer wrote: beget sounds very much like what we want, but I just wanted to raise a point about understanding and adoption, especially for the language of the web. I wouldn’t worry, all of a programming language is new vocabulary, anyway. You always have to learn semantics, so learning a new word (especially one that increases your English vocabulary) shouldn’t be a problem. If this logic is correct then we shouldn't be worrying about the word choice at all. We can just make up a word. I propose wrfs as a suitably short and meaningless word that isn't biased in favor of English speakers. Allenb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On 31 October 2011 15:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote: some others (probably all too long for Brendan's tastes): I would assume a two word combination such as super for would be too verbose to be acceptable. -- Neil ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 30, 2011, at 11:07 PM, Brendan Eich wrote: On Oct 30, 2011, at 5:55 PM, Axel Rauschmayer wrote: The only thing I find off the mark is the typography of |. In light of this, and of the anti-grawlix reaction among many people, could we revisit an infix operator used in restricted productions with [no LineTerminator here] on the left of the operator contextual keyword? I hope this is not just in deference to a few vocal opponents. That's not the way to approach this. You could be among the few vocal *pro*ponents of | -- do we need a statistically significant and valid survey? There are plenty of fonts in which the triangle appearance is ugly or lost. There are people who object independent of fonts to JS growing line-noise hair at its advanced age. These are both worth considering. They can't be dismissed with few and vocal. I've heard the line noise objection many time but I don't understand the thinking that seems to say you can only introduce new symbology into a language at its initial creation and that all post initial release extensions must be natural language based. | or : or beget is going to be a very important operator going forward and is used in expression context where the norm is special character-based operators. Adding a new symbol for such an operator seems quite reasonable. Wholesale re-grawlix-ifying the entire language would be unacceptable. Adding one or two new symbols for key features is not that. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
We've been over this before.
1. No camelCaps.
2. No oof substrings (comical!).
3. No prepositional phrases that suggest predicates, where active verbs are
requried.
/be
On Oct 31, 2011, at 4:58 AM, David Bruant wrote:
Le 30/10/2011 23:36, Brendan Eich a écrit :
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it names the initialization method
constructor in order to tie into the object construction mechanisms that
already exist in JS.
+1
The only thing I find off the mark is the typography of |. In light of
this, and of the anti-grawlix reaction among many people, could we revisit
an infix operator used in restricted productions with [no LineTerminator
here] on the left of the operator contextual keyword?
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object)
What about 'protoOf'? Operators are not camelcase ('typeof',
'instanceof'). Maybe 'protoof', but since 'proto' ends in 'o', it
doesn't look very good to me (though I'm nit an native English speaker)
let o = base protoof {a:1, b:2};
let a = base protoof [1, 2, 3];
Or,
let o = base protoOf {a:1, b:2};
let a = base protoOf [1, 2, 3];
?
I would have suggested 'prototypeof' in reference to
Object.getPrototypeOf, but I find it a bit long.
Ideas?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
beget sounds very much like what we want, but I just wanted to raise a point about understanding and adoption, especially for the language of the web. I wouldn’t worry, all of a programming language is new vocabulary, anyway. You always have to learn semantics, so learning a new word (especially one that increases your English vocabulary) shouldn’t be a problem. If this logic is correct then we shouldn't be worrying about the word choice at all. We can just make up a word. I propose wrfs as a suitably short and meaningless word that isn't biased in favor of English speakers. I like brck better. ;-) I should clarify – what I actually meant is: You can’t worry about *all* non-native speakers (super and sub must be challenging to someone whose language has not been influenced by Latin, etc.). I’ve heard about beget (“violence only begets violence”, IIRC) and it’s a combination of two easy words, so it shouldn’t be too hard to learn. I think it’s too late to remove the English bias from JavaScript (kudos to Oracle for trying – they call their JavaScript engine Nashorn). -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 9:07 AM, Axel Rauschmayer wrote: beget sounds very much like what we want, but I just wanted to raise a point about understanding and adoption, especially for the language of the web. I wouldn’t worry, all of a programming language is new vocabulary, anyway. You always have to learn semantics, so learning a new word (especially one that increases your English vocabulary) shouldn’t be a problem. If this logic is correct then we shouldn't be worrying about the word choice at all. We can just make up a word. I propose wrfs as a suitably short and meaningless word that isn't biased in favor of English speakers. I like brck better. ;-) maybe we can compromise on wrfsbrck or brckwrfs Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
I like all of them (“form” does have DOM connotations, though), the last ones should be in third person. Brendan’s “protos” could work, too, as an abbreviation for “prototypes”. On Oct 31, 2011, at 16:23 , Allen Wirfs-Brock wrote: some others (probably all too long for Brendan's tastes): provides (properties for) provisions generalizes derives spawns engenders differentiates spawn (bad concurrency connotations) parent (bad DOM connotations) Not accurately descriptive but close enough that they have some of the right connotations. build devise forge form invest Note that for many non-native English speakers probably don't have many of these words (including beget) in their vocabularies. For them, a symbolic token such as | or : is probably just as meaningful. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Sun, Oct 30, 2011 at 12:33 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Oct 29, 2011, at 10:03 PM, John J Barton wrote:
...
JS is what it is. I don't think it is possible to make prototypes
disappear without breaking many (most??) existing JS programs.
(This perfectly illustrates my objection to any new features using the word
prototype). I assume you meant to make |.prototype| disappear rather
than to make prototypical inheritance disappear. I am not suggesting
removing |.prototype|; I am suggesting that it be avoided in future work
because by now we have a lot of experience with it and its not a good thing.
I'd love to see a riff on Gozala's selfish with the declarative
approach. Maybe the gap is too large.
It has been proposed in many variations.
The basic way that object abstractions are instantiated in the self
language is via a copy/initialize sequence. You send a copy message to a
Prototype object, typically this creates a new object that inherits form
the Prototype and then invokes the initialize method on the new object to
set up and instance specific state.
In selfish, the new method is the equivalent of self's copy method and
selfish's initialize method serves a similar role to self's initialize
method. If you have to define a lot of methods (typically because the
object you are defining is going to be used as a Prototype), it's
inconvenient to do this in the initialize method, so both self and selfish
provide a way to directly define a new Prototype object. In self, this is
via its IDE and reflection API. In selfish it is via the extend method.
The object exemplar proposal I have talked about also exactly parallels
this same self/selfish model. With object exemplars, the JS new operator
corresponds to self's copy and selfish's new method. With object
exemplars the constructor method corresponds to the self/selfish
initialize method.
So where in self you would:
Derive a new prototype object named Dog from a prototype named Mammal
using the IDE.
Create a Dog instance by saying:
Dog new: 'Labrador'
which creates a new object that inherits from Dog. The initialize
method is invoked on the new instance passing Labrador as the argument.
In selfish you would:
Derive a new prototype named Dog by evaluating:
var Dog = Mammal.extend ({
initialize: function(breed) {this.breed = breed},
/* other dog methods */
});
You would create a Dog instance by saying
Dog.new(Labrador)
which creates a new object that inherits from Dog. The initialize
method is invoked on the new instance passing Labrador as the argument.
In JS using my object exemplar proposal you would:
Derive a new prototype named Dog by evaluating:
var Dog = Mammal | {
constructor: function(breed) {this.breed = breed},
/* other dog methods */
});
You would create a Dog instance by saying
new Dog(Labrador)
which creates a new object that inherits from Dog. The constructor
method is invoked on the new instance passing Labrador as the argument.
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it names the initialization method
constructor in order to tie into the object construction mechanisms that
already exist in JS.
Thanks for the excellent summary and parallel constructions. However you
missed my point. None of your examples include |.prototype|, 'dot
prototype'.
constructor vs initialize is minor, |.new| vs operator new is minor.
|.prototype|, with it's confusing relationship to objects and its
vocabulary distortions is not minor. Note that your examples above are all
clear and the property |.prototype| does not appear.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Sun, Oct 30, 2011 at 1:08 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Oct 30, 2011, at 10:39 AM, John J Barton wrote: In the abstract I would agree, but, in our world, every college sophomore CS student learns a class based language and, in our world, prototypical inheritance in JS uses a bizarre pattern of expression. ES should work make this bizarre pattern unnecessary so prototypical inheritance can shine. Using .prototype in new patterns heads in the wrong direction: that is the comment I was making on Allen's proposal. Note that my class pattern that was the topic at the beginning of this thread is not a pattern for expression prototypal inheritance. It is a pattern for expressing classical (ie, class-based) inheritance in JavaScript using existing JavaScript terminology and conventions. Thanks for that clarification. So now I just object to this entire enterprise ;-). In my opinion for new syntax to support classical inheritance should 1) target beginners and 2) help avoid the need for F.prototype/new F() pattern for simple inheritance. Creating a new, complex machine to support classical inheritance will result in lots of language discussions and a new round of libraries to work around the complexities. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 5:45 AM, Axel Rauschmayer wrote:
beget sounds very much like what we want, but I just wanted to raise a
point about understanding and adoption, especially for the language of
the web.
I wouldn’t worry, all of a programming language is new vocabulary, anyway.
You always have to learn semantics, so learning a new word (especially one
that increases your English vocabulary) shouldn’t be a problem. My worry is
more that it doesn’t read like a sentence. I would prefer
const Employee = Person begets { ... };
That's an operator, it happens in an evaluation regime at a certain time. It
should use a pidgin-English word or phrase free of tense elaboration, as
delete, in, instanceof do.
I think Java got it right with extends:
class Employee extends Person { ... }
That's a declarative form, not an operator. It uses present tense to connote
timelessness, for all time (once the declaration has been processed).
/be
What about 'protofor'?
let obj = base protofor {a: 1, b: 2}
let arr = base protofor [p, q, r]
let fun = base protofor function (...args) { ... }
let re = base protofor /(\w+)\s+(\w)+/g
Once again, for the specific case of functions, the proto operator has a
semantics that goes way beyond setting the [[prototype]] internal
property. Maybe 'protofor' for the [[prototype]] and 'beget' for the
constructor-related semantics?
Even though it contradicts my previous rules, I still tremendously like
“proto”: It does not create new vocabulary and has an operator-y feel to it.
let obj = base proto {a: 1, b: 2}
let arr = base proto [p, q, r]
let fun = base proto function (...args) { ... }
let re = base proto /(\w+)\s+(\w)+/g
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 8:49 AM, Allen Wirfs-Brock wrote: On Oct 30, 2011, at 11:07 PM, Brendan Eich wrote: On Oct 30, 2011, at 5:55 PM, Axel Rauschmayer wrote: The only thing I find off the mark is the typography of |. In light of this, and of the anti-grawlix reaction among many people, could we revisit an infix operator used in restricted productions with [no LineTerminator here] on the left of the operator contextual keyword? I hope this is not just in deference to a few vocal opponents. That's not the way to approach this. You could be among the few vocal *pro*ponents of | -- do we need a statistically significant and valid survey? There are plenty of fonts in which the triangle appearance is ugly or lost. There are people who object independent of fonts to JS growing line-noise hair at its advanced age. These are both worth considering. They can't be dismissed with few and vocal. I've heard the line noise objection many time but I don't understand the thinking that seems to say you can only introduce new symbology into a language at its initial creation and that all post initial release extensions must be natural language based. That's too dogmatic, I agree. The grawlix objection was not a rigorous one, rather an outcry against a tendency that can be overdone. And which bites back hard in some fonts. The typography issue persists. | or : or beget is going to be a very important operator going forward and is used in expression context where the norm is special character-based operators. Adding a new symbol for such an operator seems quite reasonable. Wholesale re-grawlix-ifying the entire language would be unacceptable. Adding one or two new symbols for key features is not that. No, but if the typography and quantity of punctuation-pairings is off enough, there'll be push-back and ongoing controversy. I don't see this one solving itself by exposure and familiarity. If we had a more universally triangular (pointing left) sequence, probably we wouldn't be here. My gut-check, FWIW. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
My worry is more that it doesn’t read like a sentence. I would prefer
const Employee = Person begets { ... };
That's an operator, it happens in an evaluation regime at a certain time. It
should use a pidgin-English word or phrase free of tense elaboration, as
delete, in, instanceof do
I’m not sure what the best approach is. One more idea: The examples you give
are easily turned into English.
delete foo.bar = Delete foo.bar!
bar in foo = Is bar in foo?
obj instanceof Constr = Is obj an instanceof Constr?
I think that’s why they work so well. How would you do the same for “beget”?
But “begets” isn’t any better. Maybe “begetting”? The result can indeed be
described as Person begetting an object.
Person beget { ... } = ???
Is beget an imperative here or an infinitive?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 9:45 AM, John J Barton wrote: In my opinion for new syntax to support classical inheritance should 1) target beginners and 2) help avoid the need for F.prototype/new F() pattern for simple inheritance. John, I almost-completely agree with you (yay!), except for the |new F| objection. What's wrong with operator new for class instantiation? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 9:59 AM, Axel Rauschmayer wrote:
Person beget { ... } = ???
Is beget an imperative here or an infinitive?
Both! But it's not a declarative present-tense linking form, as extends is in
class declarations (I think class literals is a terrible phrase, BTW -- too
many evaluated parts and mutability to be a literal).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On 31/10/2011, at 08:57, Brendan Eich wrote:
On Oct 31, 2011, at 12:20 AM, Jorge wrote:
Perhaps a long arrow may work ?
let object= base == {a: 1, b: 2};
Does not overcome the grawlix objection.
Hmm, it's grawlix-y too but... how about
let object= base :: {a: 1, b: 2};
?
let object= base == {a: 1, b: 2};
let object= base : {a: 1, b: 2};
let object= base | {a: 1, b: 2};
let object= base :: {a: 1, b: 2};
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 10:04 AM, Jorge wrote:
On 31/10/2011, at 08:57, Brendan Eich wrote:
On Oct 31, 2011, at 12:20 AM, Jorge wrote:
Perhaps a long arrow may work ?
let object= base == {a: 1, b: 2};
Does not overcome the grawlix objection.
Hmm, it's grawlix-y too but... how about
let object= base :: {a: 1, b: 2};
?
No, that's wanted for wiki.ecmascript.org/doku.php?id=strawman:guards --
precedent from Haskell and other languages, and the single-colon from ES4
doesn't mix well with object literals.
Grawlix is the general problem, not the solution.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 31, 2011, at 9:45 AM, John J Barton wrote:
In my opinion for new syntax to support classical inheritance should 1)
target beginners and 2) help avoid the need for F.prototype/new F() pattern
for simple inheritance.
John, I almost-completely agree with you (yay!), except for the |new F|
objection. What's wrong with operator new for class instantiation?
I don't object to operator new for creating instances. (It is more
wordy in definition than a function property new, a minor point).
My objection is the specification of methods on the |.prototype|
property of the right-hand side operand of operator new. I
understand that it makes some logical sense, but we also know that
it's confusing to even experienced developers. We can't take it back.
Can we make it's use less important? Can we avoid using this odd
relationship in future features?
We could try to analyze why the F.prototype/new F() pattern is
confusing. I think the pattern is confusing when you start where
developers start. Given an object |E|, I want to create objects with
the methods of |E| except from an override. My goals is:
let f = new F(); // F is like E but different.
So I must define F in terms of E.
In class languages I say:
class F something E withOverrides {}
In JavaScript I have to stop and think about |.prototype|. I want to
concentrate on |E| and the overrides, but instead I am re-reading
Crockford.
Immediately after this phase the class-based language pattern leads
you to think you are accomplishing great things, but mostly you are
focusing premature on abstraction details. But that critical phase
from given an object |E| to declaring |F| provides a big advantage.
I believe this is why devs gravitate to selfish and extends() models.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 10:45 AM, John J Barton wrote: On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote: On Oct 31, 2011, at 9:45 AM, John J Barton wrote: In my opinion for new syntax to support classical inheritance should 1) target beginners and 2) help avoid the need for F.prototype/new F() pattern for simple inheritance. John, I almost-completely agree with you (yay!), except for the |new F| objection. What's wrong with operator new for class instantiation? I don't object to operator new for creating instances. Great. (It is more wordy in definition than a function property new, a minor point). (Do you mean 'constructor' is a longer word than 'new'? Not sure what the parenthetical is getting at.) My objection is the specification of methods on the |.prototype| property of the right-hand side operand of operator new. I understand that it makes some logical sense, It's how JS works, that's all. Agree it should be considered plumbing to be put behind a pretty cabinet door for n00b/classy programmers. Immediately after this phase the class-based language pattern leads you to think you are accomplishing great things, but mostly you are focusing premature on abstraction details. That seems like a problem in itself. Maybe we can't solve it, and we're better off adding classes. But I've seen that over and over too. It gives me pause about class as the best or one true way. But that critical phase from given an object |E| to declaring |F| provides a big advantage. Agreed. I believe this is why devs gravitate to selfish and extends() models. Or bounce off JS. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
I've been noodling around with various syntax ideas in this post, and it
has gotten pretty long, so here are the highlights:
var obj = base | {a:1,b:2}; // I think its okay as-is.
var obj = {:base a:1, b:2}; // Its not really an operator, anyway
var obj = base prototype {a:1,b:2} // Prototype with pride!
var obj = base share {a:1,b:2} // JS: the friendly language
var obj = with(base) {a:1, b:2}; // :-)
If any of these intrigue you, read on for my thoughts on why punctuation
is okay in this case, and why I've proposed syntax that is not an operator.
I'm sympathetic to the anti-grawlix position. In this case, however,
we're discussing an operator that is *fundamental* to the language and
gets right to the heart of JavaScript's prototype system. The reason it
is hard to name is that there is no precedent in other languages.
Because it is fundamental and unique to JavaScript, people will think of
it as that weirdly cool JavaScript operator. So, do we want them
thinking that weirdly cool operator that doesn't quite look like a
triangle or that weirdly cool operator that sounds sort of biblical?
I'm only sort of joking about that. My more serious point is that
prototype-based inheritance is something that new programmers have to
take some time to learn. Having to learn one new punctuation-based
operator is really no extra effort, especially when it is such an
important one. There have been previous proposals (I'm thinking of one
for setting property attributes in object literals) that really did seem
to increase the line-noise quotient of the language. But the triangle
operator isn't one of those.
If the concern is just about the typography of | not looking triangular
enough, how about *, where shows the direction of the relationship
and * says this is really special and important :-) Or, -?
It is also worth thinking about the fact that | is a very unusual
operator because the RHS must be a literal. Like the . operator for
property access which requires an identifier on the right, it could be
considered a syntactic form that is not quite an operator. So could we
put syntax before and after the proto object to make this an easier to
understand concept? Like this:
var obj = with(base) { a:1, b:2};
Redeeming with would be pretty cool, but I assume it would cause to much
confusion to consider seriously. So what if the base object was between
the | and the arrow:
var obj = |base {a:1, b:2};
I know that changes the direction of the arrow around, but I suspect
that pointing at the derived object is actually more intuitive for most
programmers, anyway. I don't know if this syntax works in the grammar,
and it looks a little phallic (the rocket operator ;-), but to my eye,
it helps to convey what is going on better than a simple infix operator.
Or, to emphasize that this new syntactic form is all about specifying a
prototype for an object (or array, function, or regexp) how about
forcing it all to be within curly braces?
var obj = {:base a:1, b:2};
var arr = {:base [a,b,c]};
var func = {:base function(...args) {...}};
var re = {:base /pattern/g};
(I'm using a colon here instead of the vertical bar because I'm still
hoping for block lambdas...)
Setting a prototype on an array object is an unusual enough thing to do
that I think it can certainly justify the wrapping and even extra
indentation that comes with putting [] inside {}.
If its got to be an infix keyword operator, I'm not crazy about
beget. I'd prefer proto. And actually, I'd even prefer to type the
extra 4 characters and use prototype because it is a verb. JavaScript
has prototype based inheritance, so let's wear that proudly and make it
a keyword operator.
The next best I can come up with is share. (That is assuming that
sub and subclass are off-limits because ES.next.next may someday
have a class keyword.)
If the left and right-hand sides of the operator were swapped, it would
be easy to name the operator: inherit would be an obvious choice. We
need the inverse of inherit, something like designate an heir, but I
don't think English has a word with that meaning. The word heir
itself is nice and short, but I assume that the fact that it is not a
verb disqualifies it.
So if we can't find a good keyword using the
inheritance-by-children-upon-death-of-the-parents metaphor, we can go
for parent/child metaphors, which is where beget comes from. And from
biology we can go back to inheritance in the form of genetic
inheritance. If the prototype object is like DNA (and its properties
are genes) is there a verb we can draw from genetics to describe what
the operator does?
Or, can we just break away from the family tree/inheritance metaphor
entirely and just say what the operator does? That's where my share
suggestion comes from: the prototype object shares its properties with
the derived object.
David
Tachyon JS VM
Hello, I recently presented a paper about Tachyon, a research (meta-circular) JavaScript VM implementation at DLS 2011. Sam Tobin-Hochstadt suggested that I join this list and mention our effort, to get in touch with other JS implementers, and perhaps get some feedback/suggestions or contributions. Tachyon is a JavaScript VM written in (extended) JavaScript. It uses a pure JIT targetting x86/x86-64. We aim to eventually support the full ES5 spec. We have support for most of it, but we're still missing important features such as a GC, floating-point support and exceptions. Tachyon's development is funded in part by Mozilla. For those who may bee interested, here are the slides from our DLS11 talk: http://pointersgonewild.files.wordpress.com/2011/10/dls-talk.pdf And if you're really interested, here's our paper: http://www.iro.umontreal.ca/~dufour/pubs/dls2011.pdf Tachyon is open source (BSD license) and available on github. Feedback is welcome, but please bear in mind that it's a work in progress: https://github.com/T https://github.com/Tachyon-Team/Tachyon achyon-Team/Tachyon https://github.com/Tachyon-Team/Tachyon Have a nice day, - Maxime Chevalier-Boisvert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Tachyon JS VM
2011/10/31 Maxime Chevalier-Boisvert maximechevali...@gmail.com: Hello, I recently presented a paper about Tachyon, a research (meta-circular) JavaScript VM implementation at DLS 2011. Sam Tobin-Hochstadt suggested that I join this list and mention our effort, to get in touch with other JS implementers, and perhaps get some feedback/suggestions or contributions. Tachyon is a JavaScript VM written in (extended) JavaScript. It uses a pure JIT targetting x86/x86-64. We aim to eventually support the full ES5 spec. We have support for most of it, but we're still missing important features such as a GC, floating-point support and exceptions. Tachyon's development is funded in part by Mozilla. Could you explain how this differs from other meta-circular interpreters like Narcissus? Is it correct to say that this is not a tree-interpreter like Narcissus, but a JavaScript to native compiler written in JS. If it's not a tree-interpreter, then running inside a JVM that has ephemerons doesn't help you on the GC front? Does the native code generated fit within the NaCL alignment restrictions? When you say you don't have exceptions, does that mean you lack anything related to protected regions? try...finally ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Tachyon JS VM
Could you explain how this differs from other meta-circular interpreters like Narcissus? Is it correct to say that this is not a tree-interpreter like Narcissus, but a JavaScript to native compiler written in JS. Like Narcissus, it is implemented in JavaScript, but it has no interpreter. It compiles JavaScript to native x86 code. This requires some JavaScript extensions to be able to allocate executable memory blocks and write to them. If it's not a tree-interpreter, then running inside a JVM that has ephemerons doesn't help you on the GC front? Does the native code generated fit within the NaCL alignment restrictions? We're not running within a JVM. The goal is for Tachyon to eventually run on top of its own runtime library, without any external VM. For now, we've added some minor extensions to V8, which we use as our host VM. I plan on implementing a simple stop-and-copy collector for Tachyon. My aim is to write this GC in JavaScript, as much as possible. We could cheat and use an off-the-shelf GC like Boehm's. I'm afraid that the allocation speed might be a little too slow for JavaScript, however. When you say you don't have exceptions, does that mean you lack anything related to protected regions? try...finally Code that contains throw/try/catch/finally will parse and run (so long as throws don't actually happen). We can't unwind the stack, for now. I don't anticipate it will be too tricky to implement, but the backend needs to be modified to integrate meta-information w.r.t. exception handlers. - Maxime ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Tachyon JS VM
2011/10/31 Maxime Chevalier-Boisvert maximechevali...@gmail.com: If it's not a tree-interpreter, then running inside a JVM that has ephemerons doesn't help you on the GC front? Does the native code generated fit within the NaCL alignment restrictions? We're not running within a JVM. The goal is for Tachyon to eventually run on Sorry, slip of the keyboard. s/JVM/JS implementation/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Tachyon JS VM
On Oct 31, 2011, at 1:38 PM, Mike Samuel wrote: 2011/10/31 Maxime Chevalier-Boisvert maximechevali...@gmail.com: Hello, I recently presented a paper about Tachyon, a research (meta-circular) JavaScript VM implementation at DLS 2011. Sam Tobin-Hochstadt suggested that I join this list and mention our effort, to get in touch with other JS implementers, and perhaps get some feedback/suggestions or contributions. Tachyon is a JavaScript VM written in (extended) JavaScript. It uses a pure JIT targetting x86/x86-64. We aim to eventually support the full ES5 spec. We have support for most of it, but we're still missing important features such as a GC, floating-point support and exceptions. Tachyon's development is funded in part by Mozilla. Could you explain how this differs from other meta-circular interpreters like Narcissus? Is it correct to say that this is not a tree-interpreter like Narcissus, but a JavaScript to native compiler written in JS. I was asking Mike privately why he asked about this, and he answered that the meta-circular term suggested to him that there's a Tachyon interpreter or tower of evaluators. http://en.wikipedia.org/wiki/Meta-circular_evaluator I'm not an expert on meta-circular terminology, just curious to learn. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
thanks, Dave, some lateral thinking is really helpful. more below
On Oct 31, 2011, at 12:43 PM, David Flanagan wrote:
I've been noodling around with various syntax ideas in this post, and it has
gotten pretty long, so here are the highlights:
var obj = base | {a:1,b:2}; // I think its okay as-is.
var obj = {:base a:1, b:2}; // Its not really an operator, anyway
var obj = base prototype {a:1,b:2} // Prototype with pride!
var obj = base share {a:1,b:2} // JS: the friendly language
var obj = with(base) {a:1, b:2}; // :-)
what do you think of : instead of | ?
...
eem to increase the line-noise quotient of the language. But the triangle
operator isn't one of those.
If the concern is just about the typography of | not looking triangular
enough, how about *, where shows the direction of the relationship and *
says this is really special and important :-) Or, -?
if ( a-5) ...
It is also worth thinking about the fact that | is a very unusual operator
because the RHS must be a literal. Like the . operator for property access
which requires an identifier on the right, it could be considered a syntactic
form that is not quite an operator.
yes, that is what it is.
...
Or, to emphasize that this new syntactic form is all about specifying a
prototype for an object (or array, function, or regexp) how about forcing it
all to be within curly braces?
var obj = {:base a:1, b:2};
var arr = {:base [a,b,c]};
var func = {:base function(...args) {...}};
var re = {:base /pattern/g};
(I'm using a colon here instead of the vertical bar because I'm still hoping
for block lambdas...)
interesting idea, an universal object literal form...
We should experiment with what it looks like when base is a more complex
expression.
Setting a prototype on an array object is an unusual enough thing to do that
I think it can certainly justify the wrapping and even extra indentation that
comes with putting [] inside {}.
If its got to be an infix keyword operator, I'm not crazy about beget. I'd
prefer proto. And actually, I'd even prefer to type the extra 4 characters
and use prototype because it is a verb. JavaScript has prototype based
inheritance, so let's wear that proudly and make it a keyword operator.
The next best I can come up with is share. (That is assuming that sub
and subclass are off-limits because ES.next.next may someday have a class
keyword.)
If the left and right-hand sides of the operator were swapped, it would be
easy to name the operator: inherit would be an obvious choice. We need
the inverse of inherit, something like designate an heir, but I don't
think English has a word with that meaning. The word heir itself is nice
and short, but I assume that the fact that it is not a verb disqualifies it.
bequest
So if we can't find a good keyword using the
inheritance-by-children-upon-death-of-the-parents metaphor, we can go for
parent/child metaphors, which is where beget comes from. And from biology we
can go back to inheritance in the form of genetic inheritance. If the
prototype object is like DNA (and its properties are genes) is there a verb
we can draw from genetics to describe what the operator does?
Or, can we just break away from the family tree/inheritance metaphor entirely
and just say what the operator does? That's where my share suggestion
comes from: the prototype object shares its properties with the derived
object.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
If its got to be an infix keyword operator, I'm not crazy about beget. I'd prefer proto. +2 The next best I can come up with is share. (That is assuming that sub and subclass are off-limits because ES.next.next may someday have a class keyword.) +1 If the left and right-hand sides of the operator were swapped, it would be easy to name the operator: inherit would be an obvious choice. We need the inverse of inherit, something like designate an heir, but I don't think English has a word with that meaning. The word heir itself is nice and short, but I assume that the fact that it is not a verb disqualifies it. German has a word for it, my dictionary says the translation is “bequeath”. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 10:45 AM, John J Barton wrote:
On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 31, 2011, at 9:45 AM, John J Barton wrote:
In my opinion for new syntax to support classical inheritance should 1)
target beginners and 2) help avoid the need for F.prototype/new F() pattern
for simple inheritance.
John, I almost-completely agree with you (yay!), except for the |new F|
objection. What's wrong with operator new for class instantiation?
...
In class languages I say:
class F something E withOverrides {}
...
Immediately after this phase the class-based language pattern leads
you to think you are accomplishing great things, but mostly you are
focusing premature on abstraction details. But that critical phase
from given an object |E| to declaring |F| provides a big advantage.
I believe this is why devs gravitate to selfish and extends() models.
John,
I'm going to circle back to some of your other points in another message, but
first I want to address your final point.
You start in the 9:45 AM message talking about making classical inheritance
simple. However, in the final sentence you mention selfish and extends() as
the things that devs gravitate towards as a solution to that problem. But
those are both (more or less) prototypal inheritance based designs. They
aren't doing classical inheritance.
We have talked quite a bit about how we could support very simple expression of
prototypal inheritance that is very close to the ideal you seem to be looking
for:
let E = {...} //E is just some object
let F = E | { //bikesheding | is a separate topic
method1() {},
method2() {},
//etc.
};
var f = new F;
but if you want to have instance initialization behavior you would define it
like:
let F2 = E | {
method1() {},
method2() {}, //overrides
constructor(init) {
this.x = init;
}
};
var f2 = new F2(42);
We have recently taken to calling this pattern object exemplars. It is
prototypal inheritance, almost exactly equivalent to what selfish does. If we
could all be satisfied with this there would be no need for the ongoing debate.
However, some people do not seem to be satisfied.
Fundamentally, what we are trying to enable here is the simple creation of
named abstractions over sets of behaviorally related objects. This is important
became it allows devs to think and communicate about the set rather than the
individual objects. The complication comes when we must decide what sort of
runtime entity is actually assigned a name. In selfish and in the above
examples it is a regular object that is named. This object is considered to be
a prototype because it provides the prototypical behavior that is shared by
all members of the abstraction. This is what is going on in my above examples
even though the word prototype never explicitly appears.
The objection that is raised is that we are assigning the name to the wrong
kind of object. The original JavaScript approach to creating objects uses a
separately defined constructor function and it is the function that is given a
name. When you say new Array() in JS you are not referring to the prototypal
array object, instead you are referring to a function that creates arrays and
implicitly associates they with Array.prototype. Some would go as far to say
that named constructor functions are how JS manifests classes -- the
constructor functions are the class objects. Their objection to the object
exemplar pattern is that it isn't really how JS does classes.
Sometimes it sounds like what you are asking for is precisely what objects
exemplars provide. But other times you say you want classical inheritance.
Which is it?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Internationalization feedback
Nicholas, Andrea, Rick,
Thanks for your feedback. A few replies:
Why DateTimeFormat and NumberFormat as separate object types rather than
methods on Date.prototype and Number.prototype: I suspect Conway's Law played a
bit of a role here - an ad hoc team was chartered by TC 39 with developing a
separate standard, and so it did. I hope that eventually we'll be able to tie
the results back into core language classes, and have written up a strawman for
that (so far just my own musings):
http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration
Having separate objects available however is useful at times because it lets
the application find out about the results of language negotiation, and to
avoid the cost of redoing negotiation and setup for each format call.
Verbosity of object literal specification in date format: Personally, I agree
that the current spec draft is a bit complicated; I once proposed a slightly
simpler variant:
http://norbertlindenberg.com/ecmascript/internationalization-formats.html#DateTimeFormat
A simple format pattern like hh:mm:ss however doesn't give us enough
information to generate properly localized results: Does the absence of an
am/pm indicator mean you always want 24-hour time, or is that just the
preference of your language, and in others it should be 12-hour time with
am/pm? Should the Chinese version be plain numeric (12:34:56) or with the
characters for hour/minute/second (12时34分56秒)? Libraries using such patterns
usually expect applications to bring along localized patterns - we instead want
to leverage the information about hundreds of languages that the
internationalization libraries of modern operating systems already include.
ICU has skeletons, which are less language dependent than patterns, although
still not entirely language independent, and are mapped to patterns using
significant amounts of magic:
http://unicode.org/reports/tr35/#Date_Format_Patterns
If you have ideas on how to simplify the API without requiring applications to
provide localized format patterns, I'd love to hear them.
Thanks,
Norbert
On Oct 29, 2011, at 7:26 , Rick Waldron wrote:
Also +1 to Nicholas points
On the whole, the proposal is very verbose - I'm not sure how much more clear
the web development community has to be about this - they don't want to type
long Java-esque constructor names. Look at any popular library - the best
ones are those that create simple, concise syntax. This should be the first
priority of all new APIs.
Rick
On Sat, Oct 29, 2011 at 5:37 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I think the main reason to have a FormatComponent is to give each
DateTimeFormat instance a configuration state so that once you define it you
can format it automatically any time you print it out.
Said that, I am familiar as example with gmdate() PHP function or similar
string syntax as it could be %.2f for numbers and I agree these are more
handy and more JavaScripysh so that if ES.next won't have them, many
developers will try to add these shortcuts into Data.prototype object with
{writable:false,enumerable:false,configurable:false} descriptor.
This underlines one more time too much abstraction or engineering may result
into less practical usage for daily basis tasks.
+1 for Nicholas idea
On Fri, Oct 28, 2011 at 9:35 PM, Nicholas Zakas standa...@nczconsulting.com
wrote:
I've just been reviewing the internationalization spec:
https://docs.google.com/document/pub?id=1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7OVsdQBw_h5ASnMndplr=1pli=1
First off - hooray! This is long, long, long overdue.
The biggest question I have is with regards to the DateTimeFormat and
NumberFormat. I'm wondering why you've chosen to have these as separate
object types instead of adding methods onto Date.prototype and
Number.prototype, respectively? It doesn't seem like having these as separate
objects provides much more value since they mostly just use their format()
methods.
Smaller question is on specifying the format. The object literal
specification of the format seems overly verbose for dates, and perhaps also
for numbers. I'd really love to be able to do something like this:
var now = Date();
console.log(now.format(hh:mm:ss));
var price = 1010;
console.log(price.format(#,###));
I'd hypothesize that most programmers are familiar with this type of
date/numeric formatting strings as they are in use in other languages. I'd
much prefer being able to use a formatting string vs. an object literal with
multiple properties that aren't very transparent as to their consequence.
Just to emphasize: I really like the functionality in the spec, it just seems
more Java-like and verbose than what's in JavaScript right now, and I'm
wondering if there are ways to change that.
Thanks,
Nicholas
___
es-discuss mailing list
Re: Tachyon JS VM
I guess that's perhaps what people are more familiar with, but I don't think the term meta-circular should be limited to interpreters. I was using it in the same way as the Klein project (SELF in SELF) did. Perhaps the term self-hosted is more descriptive. The goal is for Tachyon to compile itself, and to eventually use Tachyon for the development of Tachyon, with the aim of simplifying the design, and perhaps eventually have Tachyon optimize itself. At the very least, I've found that this is a good case of eating your own dog food. It has certainly helped me better understand the JS semantics. - Maxime On Mon, Oct 31, 2011 at 6:27 PM, Brendan Eich bren...@mozilla.com wrote: On Oct 31, 2011, at 1:38 PM, Mike Samuel wrote: 2011/10/31 Maxime Chevalier-Boisvert maximechevali...@gmail.com: Hello, I recently presented a paper about Tachyon, a research (meta-circular) JavaScript VM implementation at DLS 2011. Sam Tobin-Hochstadt suggested that I join this list and mention our effort, to get in touch with other JS implementers, and perhaps get some feedback/suggestions or contributions. Tachyon is a JavaScript VM written in (extended) JavaScript. It uses a pure JIT targetting x86/x86-64. We aim to eventually support the full ES5 spec. We have support for most of it, but we're still missing important features such as a GC, floating-point support and exceptions. Tachyon's development is funded in part by Mozilla. Could you explain how this differs from other meta-circular interpreters like Narcissus? Is it correct to say that this is not a tree-interpreter like Narcissus, but a JavaScript to native compiler written in JS. I was asking Mike privately why he asked about this, and he answered that the meta-circular term suggested to him that there's a Tachyon interpreter or tower of evaluators. http://en.wikipedia.org/wiki/Meta-circular_evaluator I'm not an expert on meta-circular terminology, just curious to learn. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Minimalist Classes
'Evening, ES-Discuss. After poking a stick in the bees' nest this morning (apologies, Allen), and in the spirit of loyal opposition, it's only fair that I throw my hat in the ring. Here is a proposal for minimalist JavaScript classes that enable behavior that JavaScripters today desire (as evidenced by libraries and languages galore), without adding any new semantics beyond what already exists in ES3. https://gist.github.com/1329619 Let me know what you think, and feel free to fork. Cheers, Jeremy Ashkenas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
Here is a proposal for minimalist JavaScript classes that enable behavior that JavaScripters today desire (as evidenced by libraries and languages galore), without adding any new semantics beyond what already exists in ES3. https://gist.github.com/1329619 I like the philosophy behind it (as stated at the end of the file). Question: If the RHS can be any expression, e.g. class Student objectContainingStudentProperties Would extends work, too? class Student extends Human objectContainingStudentProperties That could be a problem (grammatically) if Human could also be replaced by any expression. What is your take on object exemplars? Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
This is very similar to what Dave Herman, Sam Tobin-Hochstadt and I wrote at the whiteboard after the meeting was over at the last face to face meeting. I like this pattern too but at this point we are stuck at the following: https://mail.mozilla.org/pipermail/es-discuss/2011-September/016904.html On Mon, Oct 31, 2011 at 18:57, Jeremy Ashkenas jashke...@gmail.com wrote: 'Evening, ES-Discuss. After poking a stick in the bees' nest this morning (apologies, Allen), and in the spirit of loyal opposition, it's only fair that I throw my hat in the ring. Here is a proposal for minimalist JavaScript classes that enable behavior that JavaScripters today desire (as evidenced by libraries and languages galore), without adding any new semantics beyond what already exists in ES3. https://gist.github.com/1329619 Let me know what you think, and feel free to fork. Cheers, Jeremy Ashkenas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
Hi Jeremy,
Thanks for the proposal. I've been advocating a minimalist approach to classes
for a while now; I think it's a good goal. A few of us sketched out something
similar on a whiteboard in the last face-to-face meeting; at least, it used the
object literal body. We hadn't thought of two of your ideas:
1) allowing class expressions to be anonymous
2) allowing the RHS to be an arbitrary expression
I like #1; we have a lot of agreement around classes being first-class, and
that just fits right in.
But with #2 I'm not clear on the intended semantics. You say this could be
desugared but don't provide the details of the desugaring. The RHS is an
arbitrary expression that evaluates to the prototype object (call it P), but
the extends clause is meant to determine P's [[Prototype]], right? Do you
intend to mutate P's [[Prototype]]? I wouldn't agree to that semantics.
Another thing that this doesn't address is super(). Right now in ES5 and
earlier, it's pretty painful to call your superclass's constructor:
class Fox extends Animal {
constructor: function(stuff) {
Animal.call(this, stuff);
...
}
}
In general, I think your arbitrary-expression-RHS design is incompatible with
the super keyword, which needs to be lexically bound to its class-construction
site. I'll have to think about it, though.
However, I think the approach of an object literal body (and only an object
literal body) works well. I suspect you could still implement all your examples
of dynamically-computed classes, although probably with a little more work in
some cases.
Dave
On Oct 31, 2011, at 6:57 PM, Jeremy Ashkenas wrote:
'Evening, ES-Discuss.
After poking a stick in the bees' nest this morning (apologies, Allen), and
in the spirit of loyal opposition, it's only fair that I throw my hat in the
ring.
Here is a proposal for minimalist JavaScript classes that enable behavior
that JavaScripters today desire (as evidenced by libraries and languages
galore), without adding any new semantics beyond what already exists in ES3.
https://gist.github.com/1329619
Let me know what you think, and feel free to fork.
Cheers,
Jeremy Ashkenas
___
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: Minimalist Classes
On Mon, Oct 31, 2011 at 10:13 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: I like this pattern too but at this point we are stuck at the following: https://mail.mozilla.org/pipermail/es-discuss/2011-September/016904.html Right, but stuck is just a state of mind. ;) To re-quote: 1. Don't let uninitialized objects escape 2. Ensure the shape of the instance 3. Initialization of instance properties 4. Allow const classes 5. Allow const properties 6. Play well with future type guards All IMHO: 1. Not any more of a concern here than it would be for any other function ... but perhaps I don't understand the point being made. 2. Goes completely against the grain of any dynamic language, and JavaScript especially. Let Dart explore this terrain, JS.next doesn't need to. 3. Initialization of instance properties happens inside the constructor, as in ES3. 4. I'd rather not have const, but if we do, certainly you can const a class, as a class is just an expression like any other. 5. I'd rather not have const, but if we do, certainly you can const class properties, because they're values in an object literal just like any other. 6. I'd rather not have type guards, but again, if they work with object literals, they'll work with this seamlessly. Those 6 recurring problems really don't seem too bad. If you build classes out of more fundamental syntactic building blocks (objects and prototypes) ... all of the pieces that are being developed orthogonally for JS.next should just fit together. A real issue on the other hand, would be the question of how to specify bound functions within a class definition, as JS' dynamic this makes that much harder to settle than the rest of these. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Mon, Oct 31, 2011 at 4:27 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Oct 31, 2011, at 10:45 AM, John J Barton wrote:
On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 31, 2011, at 9:45 AM, John J Barton wrote:
In my opinion for new syntax to support classical inheritance should 1)
target beginners and 2) help avoid the need for F.prototype/new F() pattern
for simple inheritance.
John, I almost-completely agree with you (yay!), except for the |new F|
objection. What's wrong with operator new for class instantiation?
...
In class languages I say:
class F something E withOverrides {}
...
Immediately after this phase the class-based language pattern leads
you to think you are accomplishing great things, but mostly you are
focusing premature on abstraction details. But that critical phase
from given an object |E| to declaring |F| provides a big advantage.
I believe this is why devs gravitate to selfish and extends() models.
John,
I'm going to circle back to some of your other points in another message,
but first I want to address your final point.
You start in the 9:45 AM message talking about making classical inheritance
simple. However, in the final sentence you mention selfish and extends() as
the things that devs gravitate towards as a solution to that problem. But
those are both (more or less) prototypal inheritance based designs. They
aren't doing classical inheritance.
I guess you think I am being inconsistent, in asking for classical
then pointing to prototypical examples. There is a bit of truth to
your claim. Before your explanations on this thread I knew that
classes were vague inferior to prototypes, mainly because I wrote too
many and yet not enough singleton classes in Java. Now I have deeper
understanding of classes (and a lower opinion of classes). But the
only aspect of my opinion on classes that matters is that we need a
simple pattern for classes. I keep coming back to 'selfish' because it
provides a 'simple' solution to prototypical inheritance.
I don't think devs are trying to solve the I want to do classical
inheritance problem. Rather they are trying to write an app that
makes sense. From this point of view a confusing pattern for classical
inheritance won't be useful. The thread-intro proposal is in my
opinion confusing and I am citing as evidence our experience with new
F()/F.prototype.
We have talked quite a bit about how we could support very simple expression
of prototypal inheritance...
We have recently taken to calling this pattern object exemplars. It is
prototypal inheritance, almost exactly equivalent to what selfish does. If
we could all be satisfied with this there would be no need for the ongoing
debate.
I could be satisfied, but I know you are not satisfied since you have
offered the pattern at the top of the thread.
...
Sometimes it sounds like what you are asking for is precisely what objects
exemplars provide. But other times you say you want classical
inheritance. Which is it?
This thread is about your interesting and provocative model for
classical inheritance in the mode of JavaScript. I'm not advocating
for classical inheritance. Rather, I'm advocating for 'simple
classical inheritance' and if we can't have simple, let's not have
classical.
What I don't want is a classical inheritance syntax that perpetuates
the confusing new F()/F.prototype paradigm and also seems more
complex than a Java-like solution.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
Hey Dave.
On Mon, Oct 31, 2011 at 10:28 PM, David Herman dher...@mozilla.com wrote:
But with #2 I'm not clear on the intended semantics. You say this could be
desugared but don't provide the details of the desugaring. The RHS is an
arbitrary expression that evaluates to the prototype object (call it P),
but the extends clause is meant to determine P's [[Prototype]], right? Do
you intend to mutate P's [[Prototype]]? I wouldn't agree to that semantics.
To be a little clearer on the mechanism, it's the basic pattern you get
from most libraries that do this sort of thing. We can use goog.inherits as
the canonical example:
http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.source.html#line1421
class Fox extends Animal {
dig: function() {}
}
Fox becomes a constructor function with a `.prototype` that is set to an
instance of Animal that has been constructed without calling the Animal()
constructor. (The usual temporary-constructor-to-hold-a-prototype two step
shuffle). All of the own properties from the RHS are merged into the empty
prototype. The only mutation here is of a brand new object. Animal is not a
prototype here, it's a class (constructor function) in its own right.
Another thing that this doesn't address is super(). Right now in ES5 and
earlier, it's pretty painful to call your superclass's constructor:
In general, I think your arbitrary-expression-RHS design is incompatible
with the super keyword, which needs to be lexically bound to its
class-construction site. I'll have to think about it, though.
super() is a separate (but very much needed) issue -- that should still
make it in to JS.next regardless of if a new class syntax does. Likewise,
super() calls should not be limited only to objects that have been build
with our new classes, they should work with any object that has a prototype
(a __proto__).
Depending on whether you implement it as a reference to the prototype, or a
reference to the prototype's implementation of the current function -- an
approach that I would prefer -- the general scheme is:
Take the current object's __proto__ and apply the method of the same name
there against the current object. If you know the name of the property, and
you have the reference to the prototype, I don't see why this would
preclude dynamic definitions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
class Fox extends Animal {
dig: function() {}
}
Fox becomes a constructor function with a `.prototype` that is set to an
instance of Animal that has been constructed without calling the Animal()
constructor. (The usual temporary-constructor-to-hold-a-prototype two step
shuffle). All of the own properties from the RHS are merged into the empty
prototype. The only mutation here is of a brand new object.
OK.
Animal is not a prototype here, it's a class (constructor function) in its
own right.
Sure, I just didn't realize you wanted copying. I thought you were doing
something like
P.__proto__ = SuperClass.prototype;
But IIUC, you're proposing a semantics where you construct a brand new object P
whose __proto__ is SuperClass.prototype and then copy all the own-properties of
the RHS into P. That's fine as far as it goes, but super still doesn't work
(see below).
Another thing that this doesn't address is super(). Right now in ES5 and
earlier, it's pretty painful to call your superclass's constructor:
In general, I think your arbitrary-expression-RHS design is incompatible with
the super keyword, which needs to be lexically bound to its
class-construction site. I'll have to think about it, though.
super() is a separate (but very much needed) issue -- that should still make
it in to JS.next regardless of if a new class syntax does. Likewise, super()
calls should not be limited only to objects that have been build with our new
classes, they should work with any object that has a prototype (a __proto__).
I wish it were possible, but Allen has convinced me that you can't make super
work via a purely dynamic definition. It has to be hard-wired to the context in
which it was created. Let me see if I can make the argument concisely.
Semantics #1: super(...args) ~=~ this.__proto__.METHODNAME.call(this.__proto__,
...args)
This semantics is just wrong. You want to preserve the same |this| as you move
up the chain of super calls, so that all this-references get the most derived
version of all other properties.
Semantics #2: super(...args) ~=~ this.__proto__.METHODNAME.call(this, ...args)
This semantics is just wrong. It correctly preserves the most derived |this|,
but if it tries to continue going up the super chain, it'll start right back
from the bottom; you'll get an infinite recursion of the first super object's
version of the method calling itself over and over again.
Semantics #3: super(...args) ~=~ this.__proto__.METHODNAME.callForSuper(this,
this.__proto__, ...args)
This semantics introduces a new implicit where did I leave off in the super
chain? argument into the call semantics for every function in the language.
It's sort of the correct dynamic semantics, but it introduces an unacceptable
cost to the language. JS engine implementors will not accept it.
Semantics #4: super(...args) ~=~ LEXICALLYBOUNDPROTO.call(this, ...args)
This semantics properly goes up the super chain via lexical references only, so
it avoids the infinite recursion of #2. It doesn't introduce any new cost to
the call semantics of JS, so it doesn't have the cost of #3.
Depending on whether you implement it as a reference to the prototype, or a
reference to the prototype's implementation of the current function -- an
approach that I would prefer -- the general scheme is:
Take the current object's __proto__ and apply the method of the same name
there against the current object. If you know the name of the property, and
you have the reference to the prototype, I don't see why this would preclude
dynamic definitions.
I thought the exact same thing when I first thought about super. But sadly, as
Allen taught me, this is semantics #2, which leads to infinite super-call
recursion.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Lecture on Dart at Stanford
On 10/29/11 at 14:59, bren...@mozilla.com (Brendan Eich) wrote: Dart is not perfect either but it hangs together slightly better. It's not to my taste, and I don't see it replacing JS by acclamation, but again: can we improve ES6 classes by reflecting on what's good in it? There will be a lecture on Dart this coming Wednesday at Stanford. Here is the announcement: Stanford EE Computer Systems Colloquium 4:15PM, Wednesday, Nov 2, 2011 Skilling Auditorium, Stanford Campus http://ee380.stanford.edu[1] Topic:A Walk on the Dart Side: A Quick Tour of Dart Speaker: Gilad Bracha Google USA About the talk: Dart is a pure object-oriented, dynamically typed language with actor based concurrency. We'll take a quick tour of the Dart programming language, focusing on its more unusual features, such as optional typing and built-in factory support. Slides: There is no downloadable version of the slides for this talk available at this time. About the speaker: Gilad Bracha is the creator of the Newspeak programming language and a software engineer at Google. Previously, he was a VP at SAP Labs, a Distinguished Engineer at Cadence, and a Computational Theologist and Distinguished Engineer at Sun. He is co-author of the Java Language Specification, and a researcher in the area of object-oriented programming languages. Prior to joining Sun, he worked on Strongtalk, the Animorphic Smalltalk System. He received his B.Sc in Mathematics and Computer Science from Ben Gurion University in Israel and a Ph.D. in Computer Science from the University of Utah. Contact information: Gilad Bracha Google Embedded Links: [ 1 ]http://ee380.stanford.edu ABOUT THE COLLOQUIUM: See the Colloquium website, http://ee380.stanford.edu, for scheduled speakers, FAQ, and additional information. Stanford and SCPD students can enroll in EE380 for one unit of credit. Anyone is welcome to attend; talks are webcast live and archived for on-demand viewing over the web. WHERE IN THE WORLD IS SKILLING AUDITORIUM: The Colloquium meets in Skilling Auditorium on the Stanford Campus. A map to help you find Skilling Auditorium and parking can be found at http://ee380.stanford.edu/Skilling-Map.png. Parking in most lots is free and unrestricted after 4PM. MAILING LIST INFORMATION: This announcement is sent to multiple mailing lists. If you are signed up on our private EE380 list you can remove yourself using the widget at the upper left hand corner of the Colloquium web page. Other lists have other management protocols. --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: More thoughts on Allen’s class definition pattern
On Oct 31, 2011, at 7:37 PM, John J Barton wrote:
On Mon, Oct 31, 2011 at 4:27 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
We have talked quite a bit about how we could support very simple expression
of prototypal inheritance...
We have recently taken to calling this pattern object exemplars. It is
prototypal inheritance, almost exactly equivalent to what selfish does. If
we could all be satisfied with this there would be no need for the ongoing
debate.
I could be satisfied, but I know you are not satisfied since you have
offered the pattern at the top of the thread.
...
Actually, I would be quite satisfied with object exemplars as the primary
pattern for defining named abstractions over objects. The class pattern at the
head of the thread is put forward in a attempt to satisfy those who are
insisting on a class definition construct that fully supports all of the
really complex features of class abstractions that show up in other class-based
dynamic object-oriented languages (and additional new requirements) and also
fully supports the class pattern that is implicit in the ES built-ins. What I
am trying to show that those requirements could be satisfied based upon a
compositional pattern using just | and .{ . My belief that such a
compositional solution is adequate and better than trying to define a very
complex class semantics that may prove to be defective in the long run.
Sometimes it sounds like what you are asking for is precisely what objects
exemplars provide. But other times you say you want classical
inheritance. Which is it?
This thread is about your interesting and provocative model for
classical inheritance in the mode of JavaScript. I'm not advocating
for classical inheritance. Rather, I'm advocating for 'simple
classical inheritance' and if we can't have simple, let's not have
classical.
It actually sounds like you are advocating for prototypal inheritance that is
as simple to use as simple uses of classical inheritance in some languages. I
totally agree.
What I don't want is a classical inheritance syntax that perpetuates
the confusing new F()/F.prototype paradigm and also seems more
complex than a Java-like solution.
I agree. Except that I am fine with expert using those technique if them find
them appropriate and also having them available to framework and transpiler
authors.
Allen
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
On Mon, Oct 31, 2011 at 11:11 PM, David Herman dher...@mozilla.com wrote: But IIUC, you're proposing a semantics where you construct a brand new object P whose __proto__ is SuperClass.prototype and then copy all the own-properties of the RHS into P. Not quite. P is a constructor function (class object), SuperClass is a constructor function. Unless I'm confused, P's .prototype is an instance of SuperClass, and therefore instances of P have an RHS own-property-filled __proto__ object that itself has a __proto__ object pointing at SuperClass.prototype. Fun stuff. I wish it were possible, but Allen has convinced me that you can't make super work via a purely dynamic definition. It has to be hard-wired to the context in which it was created. Let me see if I can make the argument concisely. Semantics #1: super(...args) ~=~ this.__proto__.METHODNAME.call(this.__proto__, ...args) This semantics is just wrong. You want to preserve the same |this| as you move up the chain of super calls, so that all this-references get the most derived version of all other properties. Semantics #2: super(...args) ~=~ this.__proto__.METHODNAME.call(this, ...args) This semantics is just wrong. It correctly preserves the most derived |this|, but if it tries to continue going up the super chain, it'll start right back from the bottom; you'll get an infinite recursion of the first super object's version of the method calling itself over and over again. Semantics #3: super(...args) ~=~ this.__proto__.METHODNAME.callForSuper(this, this.__proto__, ...args) This semantics introduces a new implicit where did I leave off in the super chain? argument into the call semantics for every function in the language. It's sort of the correct dynamic semantics, but it introduces an unacceptable cost to the language. JS engine implementors will not accept it. Semantics #4: super(...args) ~=~ LEXICALLYBOUNDPROTO.call(this, ...args) Indeed, super() is tricky. For what it's worth, CoffeeScript's class syntax requires literal (non-expression) class body definitions in part to make Semantics #4 possible, with purely lexical super calls. Your example's LEXICALLYBOUNDPROTO is CoffeeScript's ClassObject.__super__. Fortunately, y'all have the ability to bend the runtime to your will. To solve the super() problem, you can simply have the JavaScript engine keep track of when a function has called through the `super()` boundary, and from that point on downwards in that method's future call stack, add an extra `__proto__` lookup to each super resolution. When the inner `super()` is then called in the context of the outer `this`, the result will be a variant of #2: this.__proto__.__proto__.METHODNAME.call(this, ...args) ... and it should work. There may be something wrong with the above -- but dynamic super() should be a solveable problem for JS.next, even if not entirely desugar-able into ES3 terms. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Minimalist Classes
But IIUC, you're proposing a semantics where you construct a brand new object P whose __proto__ is SuperClass.prototype and then copy all the own-properties of the RHS into P. Not quite. P is a constructor function (class object), SuperClass is a constructor function. Unless I'm confused, P's .prototype is an instance of SuperClass, Oh sorry, we're just miscommunicating about what's labeled what -- I was using P to name the .prototype of the subclass constructor. Let me be concrete: class SubClass extends SuperClass RHS I was using P as the name of the new object created and stored as SubClass.prototype. Then P.__proto__ is SuperClass.prototype, and the own-properties of the object that RHS evaluates to are copied into P. Instances O of SubClass have O.__proto__ === P. and therefore instances of P have an RHS own-property-filled __proto__ object that itself has a __proto__ object pointing at SuperClass.prototype. Fun stuff. Wh... Indeed, super() is tricky. For what it's worth, CoffeeScript's class syntax requires literal (non-expression) class body definitions in part to make Semantics #4 possible, with purely lexical super calls. Your example's LEXICALLYBOUNDPROTO is CoffeeScript's ClassObject.__super__. Fortunately, y'all have the ability to bend the runtime to your will. To solve the super() problem, you can simply have the JavaScript engine keep track of when a function has called through the `super()` boundary, and from that point on downwards in that method's future call stack, add an extra `__proto__` lookup to each super resolution. When the inner `super()` is then called in the context of the outer `this`, the result will be a variant of #2: this.__proto__.__proto__.METHODNAME.call(this, ...args) ... and it should work. This doesn't sound right to me. What happens if you call the same method on another object while the super-resolution is still active for the first call? IOW, this sounds like it has similar problems to dynamic scope; the behavior of a function becomes sensitive to the context in which it's called, which is unmodular. There may be something wrong with the above -- but dynamic super() should be a solveable problem for JS.next, even if not entirely desugar-able into ES3 terms. The problem isn't so much whether it's possible to come up with a semantics by changing the runtime; I'm sure we could do that. The problem is finding a way to get the semantics you want without taxing the performance all other function calls in the language. (Also known as a pay-as-you-go feature: if you don't use the feature, it shouldn't cost you anything.) We don't know how to do that for super(). So I guess in theory I agree it'd be nice if super() and class could be designed completely orthogonally, but in practice they affect each other. But at the same time, I think a class syntax where the body is restricted to be declarative is actually a nice sweet spot anyway. You can still dynamically create classes just like always, but the declarative form gives you a sweet and simple syntax for the most common case. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
