Dave,
I agree with your goal of simplifying things in this area. In that regard, I
think you bare-miniumn requirements align quite nicely with prototypes as
classes as has been recently discussed here. In case you haven't followed all
the twists of the discussion, Axel Rauschmayer has a nice
Is it too late to incorporate errata for 5.1 already? :)
It seems that the algorithm specified in 10.5 is wrong. In order to
make sense, and match the informal description at the beginning of
Section 10.6, step 8 needs to take place before step 6. (Noticed by
Steven Keuchel.)
/Andreas
On Jun 28, 2011, at 12:34 PM, Bob Nystrom wrote:
I like the simplicity of this, but I'm not crazy about how it merges two
distinct objects into one. TodayJS (and most class-based languages) let you
distinguish two things:
1. A set of properties relevant to the class itself.
2. A set of
http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance
that this kind of API will make it into Harmony? It would be really useful for
a variety of generative/meta-programming tasks.
Axel
--
Dr.
On Jun 28, 2011, at 8:34 PM, Bob Nystrom wrote:
I like the simplicity of this, but I'm not crazy about how it merges two
distinct objects into one. TodayJS (and most class-based languages) let you
distinguish two things:
(actually in the today's most widely used class-based languages
On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer a...@rauschma.de wrote:
http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
I’ve just read D. Herman’s post on Firefox’s parser API. Is there any chance
that this kind of API will make it into Harmony? It would be really
On Tue, Jun 28, 2011 at 3:34 PM, Bob Nystrom rnyst...@google.com wrote:
I like the simplicity of this, but I'm not crazy about how it merges two
distinct objects into one. TodayJS (and most class-based languages) let you
distinguish two things:
1. A set of properties relevant to the class
On Tue, Jun 28, 2011 at 5:02 PM, Mike Shaver mike.sha...@gmail.com wrote:
On Tue, Jun 28, 2011 at 6:34 PM, Axel Rauschmayer a...@rauschma.de
wrote:
http://blog.mozilla.com/dherman/2011/06/28/the-js-parser-api-has-landed/
I’ve just read D. Herman’s post on Firefox’s parser API. Is there
From: Bob Nystrom rnyst...@google.com
Date: June 28, 2011 21:34:30 GMT+02:00
Subject: Re: Summary: prototypes as classes
=== Class methods becoming instance methods ===
I agree: This one point is weirder with PaCs than with constructors. It would
be great if global variables (as in “the
On Jun 28, 2011, at 4:12 PM, Axel Rauschmayer wrote:
Explaining constructors-as-classes is really hard, explaining subclassing is
even harder.
This really depends on the student's background and previous experience. It is
not universally true.
I bet that in the coming year more new people
Plus, the prototype is in some ways secondary. It's the less directly used
object when one calls a constructor often, after populating the prototype.
And if class methods come into the picture, the prototype is even more
backstage, an implementation detail.
That seems to be a matter of
Ooo that's exciting! And so, if I'm not being too presumptuous, Does
this mean that constructions like if, while, etc become prefix
operators that can invoke a block lambda?
I've been flat out and haven't been able to look at this so it''s
exciting to see some progress on it. Just in case:
I
On Tue, Jun 28, 2011 at 3:56 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
(actually in the today's most widely used class-based languages (Java, C#,
C++) a class is no an object at all and don't have
properties/fields/polymorphic methods/etc. they really are just a scoping
mechanism. What
Maybe we could start with an “official” separate JavaScript-only implementation?
On Jun 29, 2011, at 1:05 , Mark S. Miller wrote:
Hi Axel, I'm glad you're asking the right question. To clarify for everyone,
EcmaScript-Harmony (or just Harmony) names our agreed trajectory for the
language
On Jun 28, 2011, at 4:22 PM, Axel Rauschmayer wrote:
Plus, the prototype is in some ways secondary. It's the less directly used
object when one calls a constructor often, after populating the prototype.
And if class methods come into the picture, the prototype is even more
backstage, an
As an aside:
- Static methods in Java always felt like a hack, because Java’s creators
couldn’t bring themselves to support first-class functions.
- Thus: I would much prefer to put Object.* methods into a module (once we have
those). The same holds for “class methods” such as Math.*. There Math
On Jun 28, 2011, at 4:35 PM, Breton Slivka wrote:
Ooo that's exciting! And so, if I'm not being too presumptuous, Does
this mean that constructions like if, while, etc become prefix
operators that can invoke a block lambda?
There's no point redoing the built-in statements that way, and we
Yeah, tough questions. I don't know. I tried to make the API flexible by
allowing custom builders, and in fact if you look at the test suite you'll see
I did a proof-of-concept showing how you could generate the format that Mark
mentioned:
On Tue, Jun 28, 2011 at 5:19 PM, Axel Rauschmayer a...@rauschma.de wrote:
As an aside:
- Static methods in Java always felt like a hack, because Java’s creators
couldn’t bring themselves to support first-class functions.
- Thus: I would much prefer to put Object.* methods into a module (once we
On Jun 28, 2011, at 4:41 PM, Bob Nystrom wrote:
From my view, JS-of-today is no less prototype-based than what Axel is
proposing, it just wires things up a bit differently. Or is there something
I'm missing?
Brendan here, you know, the idiot who perpetrated JS. You are not missing
On Jun 28, 2011, at 5:30 PM, Axel Rauschmayer wrote:
What do you do with constructors-as-classes to check the following?
o instanceof C
You look for C.prototype in the prototype chain of o.
No, the JS engine does that!
I, or random classy-dynamic-language-experienced users, just do
But with PaCs you don’t have to deconstruct, there is no detour from the
class to another construct.
I just wrote that with classes or today's constructor functions, no one has
to deconstruct, either.
Sorry, I meant there is nothing more going on behind the scenes. I remember
when I
On Jun 28, 2011, at 5:45 PM, Axel Rauschmayer wrote:
But before you've created an instance, it is pretty handy to have the
constructor bound to a name so you can get to it. I don't think making the
named object be the constructor means that they're *more* important, just
that you generally
On Jun 28, 2011, at 5:55 PM, Brendan Eich wrote:
The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a,
b) with extra rules for object return value, which is a complexity.
Sorry, that was unclear: I meant the indirection through .constructor was a
complexity, not the
Sorry for dragging this out. The following should be my last email in this
thread.
The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a,
b) with extra rules for object return value, which is a complexity.
Especially for abstractions that want to be callable without
On Jun 28, 2011, at 6:33 PM, Axel Rauschmayer wrote:
Sorry for dragging this out. The following should be my last email in this
thread.
Axel, thanks for interacting, nothing to apologize for here.
The prototypes-as-classes approach makes new C(a,b) invoke C.constructor(a,
b) with extra
On Tue, Jun 28, 2011 at 6:38 PM, Brendan Eich bren...@mozilla.com wrote:
It's true, classes want to slide down various lower slopes, over time. The
lint brush problem, I called it. We on TC39 are obligated to hold the
line.
Have you seen this occur in practice? My impression from C++ and C#
On Jun 28, 2011, at 6:45 PM, Bob Nystrom wrote:
On Tue, Jun 28, 2011 at 6:38 PM, Brendan Eich bren...@mozilla.com wrote:
It's true, classes want to slide down various lower slopes, over time. The
lint brush problem, I called it. We on TC39 are obligated to hold the line.
Have you seen this
I’m not arguing in favor of prototypes-as-classes, just against the assertion,
below.
There has to be a constructor function somewhere, somehow. The issue is what
name you invoke it by when calling vs. constructing. With
constructor-as-class it's the same name, the name of the abstraction
On Jun 28, 2011, at 8:36 PM, Axel Rauschmayer wrote:
I’m not arguing in favor of prototypes-as-classes, just against the
assertion, below.
I think you missed my point. You can't call a prototype -- it's generally not
callable. But in the PaC proposal you can 'new' it.
/be
30 matches
Mail list logo
