I agree with Brendan's replies, but just to add some more color:
On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll anguscr...@gmail.com wrote:
The concept itself is very simple - a dynamic archetype to be shared by all
my instances: my prototype changes, my instances know about it. I would not
On 12.07.2011 0:18, Bob Nystrom wrote:
I agree with Brendan's replies, but just to add some more color:
On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll anguscr...@gmail.com
mailto:anguscr...@gmail.com wrote:
The concept itself is very simple - a dynamic archetype to be
shared by all my
I am warming up to class literals: they should help IDEs and will make future
extensions easier (mixins etc.). Note that they are not mutually exclusive with
prototypes as classes.
On Jul 11, 2011, at 22:18 , Bob Nystrom wrote:
I agree with Brendan's replies, but just to add some more color:
I think its important to make a distinction between chained and unchained
prototypes...
By unchained prototypes I mean those that directly extend Object.prototype
(note that that every built-in prototype specified by ES5 is
unchained). Unchained prototypes are gorgeous - one instance defining
On Jul 2, 2011, at 2:04 PM, Brendan Eich wrote:
Remember, I'm the one who is a little sad about classes making the ES.next
cutoff. Also I agree with dherman that they have too many option
open, of course
issues and would benefit from reductions (minimal classes, see ).
On Jul 2, 2011, at 4:10 PM, Angus Croll wrote:
I'd argue its a difference in meaning - the proof is that if you removed
'extends' and 'super', the class sugar would support unchained prototypes
only. In fact maybe I could live with 'class' alone (though it might give
noobs the wrong idea
From: Axel Rauschmayer a...@rauschma.de
On the other hand people may find Point.new(x, y) as intuitive, as they will
think of ruby instead of java.
As an aside, you can see API code for the above functionality here:
- https://github.com/Gozala/selfish [Irakli, updated]
-
That is complexity that is added to make things compatible with constructor
functions and current built-ins. If you have to factor that in, then it is
indeed hard to argue in favor of prototypes-as-classes.
There has to be a constructor function somewhere, somehow. The issue is what
name
On Jun 29, 2011, at 1:48 PM, Axel Rauschmayer wrote:
Prototypes-as-classes (starting from scratch, with a clean protocol that has
no notion of constructor functions):
new C(x,y)
desugars (conceptually!) to
(new C).constructor(x,y)
With:
(1) Instantiation: new C
(2)
That's all neat in a kind of desugaring ftw, nerdcore way, but tl;dr -- users
don't care and they want to write new C and have it just work (mostly;
granted some crack the code, for a few good and bad purposes).
Note that I am arguing from the perspective of a language that only has PaCs,
On Jun 29, 2011, at 2:24 PM, Axel Rauschmayer wrote:
That's all neat in a kind of desugaring ftw, nerdcore way, but tl;dr --
users don't care and they want to write new C and have it just work (mostly;
granted some crack the code, for a few good and bad purposes).
Note that I am arguing
Last concrete disagreement we had was over new C() vs. C() in the current
language being notably different from new C() vs. C.constructor() in the
alternate-reality language with prototypes as classes.
As in “don’t mix too well”. I agree with that. That will be a challenge for
class
There have been multiple thread on this and I did not know were to comment, so
I'll add few comments here.
I think that whole constructors as classes business in JS is confusing for
everyone coming to JS, and they only understand it after understanding
confusing constructor- prototype
On the other hand people may find Point.new(x, y) as intuitive, as they will
think of ruby instead of java.
As an aside, you can see API code for the above functionality here:
- https://github.com/Gozala/selfish [Irakli, updated]
- http://dl.2ality.com/dl/2011/06/Proto.js [me]
--
Dr. Axel
On 6/30/11 at 17:46, rfo...@gmail.com (Irakli Gozalishvili) wrote:
I think that whole constructors as classes business in JS is
confusing for everyone coming to JS, and they only understand
it after understanding confusing constructor- prototype relationship.
I don't know about others, but I
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
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 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
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
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
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
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 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
34 matches
Mail list logo
