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
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,
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
___
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
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,
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
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
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):
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
'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
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
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:
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
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.
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
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
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
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
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
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
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
55 matches
Mail list logo
