Hi,
Sorry have not had a chance to reply on this thread earlier. I do really like
the direction that Jeremy pushes to, but still I don't understand why do we
need to introduce new syntax to the language. I think `class` expression is
completely unnecessary, why not a function ? I forked
So to clarify, is the dynamic super issue the whole reason that Jeremy's
dynamic construction of classes is considered not doable? Because it seems to
me that super may not be worth that trade off. Besides, Python's super
implementation requires the hardcoding of the class and that doesn't
What is super-intuitive about running 'class C' up against an arbitrary
expression, which is then evaluated and *copied* (details fuzzy here) as the
class prototype?
Arguments about feelings and intuition are not that helpful. Saying why you
need to construct a class that way, where no such
I noticed the absence of setter's, getter's. Would this be valid syntax?
set health(value) {
if (value 0) {
throw new Error(Health must be non-negative.);
}
@health = value;
}
On Nov 3, 2011, at 12:17 AM, Brendan Eich bren...@mozilla.com wrote:
What is super-intuitive
Sorry, I'll try to be more clear.
What's super-intuitive isn't *that* you use the form class name expr, it's
how you interact with that form once you know what it does. The reason is
self-evident—people know how to work with object literals and functions. This
is not true of the Leather form
There are many more, I'm sure, but the point is this: a syntax that makes
use of the elements already in the language (instead of providing
alternates) is going to be more familiar and therefore objectively more
intuitive. Yes, the class keyword brings some new wrinkles, but that will
be
On Nov 3, 2011, at 1:23 AM, Kam Kasravi wrote:
I noticed the absence of setter's, getter's. Would this be valid syntax?
Yes, that's already in object literal syntax.
My gist is a fork of Jeremy's, he didn't add 'em so I didn't either. At this
point they are context, assumed. They're in ES5!
On Nov 3, 2011, at 6:53 AM, Matthew Tretter wrote:
Sorry, I'll try to be more clear.
What's super-intuitive isn't *that* you use the form class name expr,
it's how you interact with that form once you know what it does. The reason
is self-evident—people know how to work with object
On 11/02/2011 04:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this impression that you are accessing the private property
(other@name) of an instance which isn't you (other !== this)
On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
[Oops. Replied to Brendan personally rather than reply-all to the list.]
My reply was private too. Here it is:
On Nov 1, 2011, at 10:15 PM, David Flanagan wrote:
On 11/1/11 5:18 PM, Brendan Eich wrote:
Love it or hate it, I'm ok either
The new more object-literal-style syntax is great. private sticks out a bit,
but it’s not a deal-breaker. It could even be good for the code if it had to
appear at the beginning (kind of like a section). Such a section would be great
for object literals, too. Maybe we can find a syntax that
super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
What is that you don’t like about Allen’s proposal? You are still hard-coding
the name of the super-constructor (which is what `super` nicely avoids).
If
On 02/11/11 11:01, Erik Corry wrote:
2011/11/2 Axel Rauschmayera...@rauschma.de:
super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
What is that you don’t like about Allen’s proposal? You are still
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, )
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non-writability,
non-enumerability, private names, const
I don’t think Allen’s proposal is controversial, any more. It’s how things work
in almost all mainstream (OO) languages. I don’t see myself using `super`
anywhere outside an object literal – except for a few cases where
Object.defineMethod() works just fine. Do you have any real-world examples
On 02/11/11 13:01, David Bruant wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, )
Regarding const, it's an optional keyword basically telling the
interpreter hey, the value isn't suppose
Does object@name break encapsulation? One could mutate object@name for any
instance of the class passed in via a parameter for example.
On Nov 2, 2011, at 8:01 AM, David Bruant bruan...@gmail.com wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed
Le 02/11/2011 16:15, Quildreen Motta a écrit :
On 02/11/11 13:01, David Bruant wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and
their object-lockdown friends, )
Regarding const, it's an optional keyword basically
That said, there are some valid use-cases for it... I guess?
Encapsulation? Stability of interfaces? Better readability? The use case is
more about code quality and expressiveness rather than adding a new
capability to the language.
The two most interesting use cases I see are (for all my
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this impression that you are accessing the private property
(other@name) of an instance which
On Nov 2, 2011, at 5:34 AM, Axel Rauschmayer wrote:
I think the namespacing via this is a feature, it give the code a nice
uniform look:
if (this.foo === other.foo)
You can use this@priv == other@priv if you like. My proposal, after Ruby and
CoffeeScript, is to support @priv (with [no
On Nov 2, 2011, at 6:26 AM, Jeremy Ashkenas wrote:
That said, we should take care to have the two things be fully consistent: A
class body should *be* an object literal, with no subtle differences in the
grammar leading to stumbling blocks down the line. If class bodies can have:
class
On Nov 2, 2011, at 8:25 AM, Kam Kasravi wrote:
Does object@name break encapsulation? One could mutate object@name for any
instance of the class passed in via a parameter for example.
At the Nov. 2008 TC39 meeting, we agreed on class-private instance variables,
not instance-private ivars.
2011/11/2 Quildreen Motta quildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any function to any
object and it'll most
On 11/1/11 11:53 PM, Brendan Eich wrote:
On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
1) Class bodies are new syntax, so you can introduce new keywords,
right? So 'prop' or 'proto'? 'static' puts a property on the class.
'private' puts a (private) property on the instance. So 'proto'
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any
On Nov 2, 2011, at 10:35 AM, David Bruant wrote:
Le 02/11/2011 18:09, Brendan Eich a écrit :
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name === other@name;
}
}
-
I am under this
On Nov 2, 2011, at 10:42 AM, Erik Corry wrote:
troll C++ requires you to state the name of the super-class in super
calls, and Java doesn't. Do we want to be like Java? /troll
Wimpy Troll, easily defeated. We want to be like Ruby and CoffeeScript!
/be
On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
On 11/1/11 11:53 PM, Brendan Eich wrote:
On Nov 1, 2011, at 10:27 PM, David Flanagan wrote:
1) Class bodies are new syntax, so you can introduce new keywords, right?
So 'prop' or 'proto'? 'static' puts a property on the class. 'private'
Le 02/11/2011 19:00, Brendan Eich a écrit :
On Nov 2, 2011, at 10:35 AM, David Bruant wrote:
Le 02/11/2011 18:09, Brendan Eich a écrit :
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name ===
On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an
On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
See my reply to Kam. We're not sugaring instance-private ivars. I am
proposing something we agreed to in Nov. 2008: sugaring class-private ivars.
Ok, that's what I was missing. What were the rationale? use cases?
The rationale is that most
On 02/11/11 16:21, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that
On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:
On Nov 2, 2011, at 11:29 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
See my reply to Kam. We're not sugaring instance-private ivars. I am
proposing something we agreed to in Nov. 2008:
To bring the comments back around a little bit to this original proposal.
One thing I can't get over with this proposal is how obvious the syntax makes
the semantics. I didn't actually have to read any of the descriptions to figure
out how all of this works, my mind made a set of assumptions
On Nov 2, 2011, at 1:20 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 2, 2011, at 1:17 PM, Kam Kasravi wrote:
On Nov 2, 2011, at 11:29 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 2, 2011, at 11:17 AM, David Bruant wrote:
See my reply to Kam. We're not sugaring
On Wed, Nov 2, 2011 at 13:39, Mikeal Rogers mikeal.rog...@gmail.com wrote:
var generateModelClass = function(columns) {
var definition = {};
columns.forEach(function(col) {
definition['get' + col] = function() {
return this[col];
};
definition['set' + col] =
On 11/2/11 11:16 AM, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
Could they have initializers that were automatically included in
the constructor?
I answered that in a gist comment. Yes, I like the CoffeeScript
constructor(@x, @y){} shorthand. Dart picked up on
On Nov 2, 2011, at 3:08 PM, David Flanagan wrote:
On 11/2/11 11:16 AM, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, David Flanagan wrote:
Could they have initializers that were automatically included in the
constructor?
I answered that in a gist comment. Yes, I like the
Updated: https://gist.github.com/1332193
$ git commit -a -mUpdates per conversations with @dflanagan and @allenwb.
git diff output below. Exec. summary: prefix groups via { ... } and public
@-namespace population to avoid this. sad-making verbosity.
/be
diff --git a/minimalist-classes.js
On Nov 2, 2011, at 7:00 PM, Brendan Eich wrote:
Updated: https://gist.github.com/1332193
$ git commit -a -mUpdates per conversations with @dflanagan and @allenwb.
git diff output below. Exec. summary: prefix groups via { ... } and public
@-namespace population to avoid this. sad-making
Last followup for tonight:
$ git diff
diff --git a/minimalist-classes.js b/minimalist-classes.js
index 7d8195e..d6bdab2 100644
--- a/minimalist-classes.js
+++ b/minimalist-classes.js
@@ -212,9 +212,9 @@ class Monster {
public flair, // you should have 37 pieces of public flair
I'm totally in agreement with Jeremy's class id objectLiteral proposal, but
for one thing: don't give up on your function definition syntax yet!
I really don't see any reason for adding a new way to define function
(methods). This:
class Runner {
run(a) {
}
}
is just as
On Nov 2, 2011, at 10:38 PM, Matthew Tretter wrote:
Introducing yet another syntax for creating a function feels like bloat to
me.
It's not just for creating a function. Method definition syntax was proposed a
while ago and it makes the method non-enumerable and binds super correctly.
While the class literal proposed by Jeremy is indeed nice, I think it
misses the point of *why* class literals are desirable. What you've
proposed can already be achieved, with the same sugar -- and without
introducing a new construct, so people using ES3 can also get it through a
library, etc --
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
On 01.11.2011 17:53, Jeremy Ashkenas wrote:
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
I think one piece of this is worth reiterating: As long as JS.next classes
are mostly sugar for prototypes, and prototypes aren't going to be deprecated
or removed in the next version of JavaScript (two propositions that I think
most of us can get behind) ... then it's very important that
The rest you could do as-is; the difference here is minimal, and IMO it's
a good thing to distinguish the fixed structure from the dynamically
computed structure. Anyway, JS has plenty of precedent for that.
Yep -- we're 98% in agreement about these, and the difference here is
indeed quite
On Tue, Nov 1, 2011 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Nov 1, 2011, at 6:53 AM, Jeremy Ashkenas wrote:
The complication of super is that each super call requires two independent
pieces of state in additional to the method arguments: the object that will
be used as
Why isn't the |super| lookup-point |this.getPrototypeOf()|
Assume |super| is |this.getPrototypeOf()|
Let F be a class, let f be an instance of the class.
inside f you have access to a method defined on F.
If you call a method defined on F from f and that method calls super, you
would be
On Nov 1, 2011, at 9:45 AM, Allen Wirfs-Brock wrote:
The complication of super is that each super call requires two independent
pieces of state in additional to the method arguments: the object that will
be used as the |this| value of the resulting method invocation and the object
where
If you have a prototype chain of objects, |this| will always point to the
beginning of the chain (which is also where properties are created whenever you
set a property via |this|). This is what allows methods in the prototype to
access instance properties.
If there is a method m in any of the
On 01.11.2011 21:30, Jake Verbaten wrote:
Why isn't the |super| lookup-point |this.getPrototypeOf()|
Assume |super| is |this.getPrototypeOf()|
Let F be a class, let f be an instance of the class.
inside f you have access to a method defined on F.
If you call a method defined on F from
On 01.11.2011 21:34, Axel Rauschmayer wrote:
If you have a prototype chain of objects, |this| will always point to
the beginning of the chain (which is also where properties are created
whenever you set a property via |this|). This is what allows methods
in the prototype to access instance
If I am not mistaken, this approach would not work with
Function.prototype.call, which lets you pick any method and hand in an
arbitrary |this|. That means you skip a step in the tracking that you are
performing.
If Dave (and you) is talking about the problem of i-looping at resolving
On 01.11.2011 21:41, Axel Rauschmayer wrote:
If I am not mistaken, this approach would not work with
Function.prototype.call, which lets you pick any method and hand in an
arbitrary |this|. That means you skip a step in the tracking that you
are performing.
Can you show an example (and
On Nov 1, 2011, at 10:47 AM, Dmitry Soshnikov wrote:
The technique I showed of course initially is designed to be used with
class-system; though, I think it can be adopted to class-free system as well.
We're not going to delete and restore. That's a non-starter for performance and
observable
I'm afraid that this super() discussion has gotten way off topic from the
actual minimalist classes thread (which would be much more fun to talk
about) -- but in the interest of dynamic class bodies, let's run it down.
On Tue, Nov 1, 2011 at 12:45 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote
On 01.11.2011 21:57, Brendan Eich wrote:
On Nov 1, 2011, at 10:47 AM, Dmitry Soshnikov wrote:
The technique I showed of course initially is designed to be used
with class-system; though, I think it can be adopted to class-free
system as well.
We're not going to delete and restore. That's a
On 01.11.2011 22:21, Axel Rauschmayer wrote:
Can you show an example (and also the same example which is solved by
es-proposed super-calls)?
let A = {
describe() {
return A;
}
}
let B = A | {
describe() {
return B+super.describe();
}
}
let C = B | {
On Nov 1, 2011, at 11:04 AM, Jeremy Ashkenas wrote:
I'm afraid that this super() discussion has gotten way off topic from the
actual minimalist classes thread (which would be much more fun to talk about)
I agree and it's probably why I may sound slightly grumpy. Dealing with super
On Nov 1, 2011, at 12:27 PM, Jeremy Ashkenas wrote:
On Tue, Nov 1, 2011 at 3:21 PM, Axel Rauschmayer a...@rauschma.de wrote:
Another problem: What if an instance method makes a super-call?
A slightly less elegant (and performant) variant of your solution that works
in both of the above
On Nov 1, 2011, at 12:46 PM, Allen Wirfs-Brock wrote:
On Nov 1, 2011, at 12:27 PM, Jeremy Ashkenas wrote:
On Tue, Nov 1, 2011 at 3:21 PM, Axel Rauschmayer a...@rauschma.de wrote:
Another problem: What if an instance method makes a super-call?
A slightly less elegant (and performant)
On Nov 1, 2011, at 11:06 AM, Allen Wirfs-Brock wrote:
On Nov 1, 2011, at 10:57 AM, Brendan Eich wrote:
On Nov 1, 2011, at 10:47 AM, Dmitry Soshnikov wrote:
The technique I showed of course initially is designed to be used with
class-system; though, I think it can be adopted to class-free
On 01.11.2011 22:53, Axel Rauschmayer wrote:
Can you show an example (and also the same example which is solved by
es-proposed super-calls)?
The technique I showed of course initially is designed to be used with
class-system; though, I think it can be adopted to class-free system as well.
On 01.11.2011 23:46, Allen Wirfs-Brock wrote:
On Nov 1, 2011, at 12:27 PM, Jeremy Ashkenas wrote:
On Tue, Nov 1, 2011 at 3:21 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
Another problem: What if an instance method makes a super-call?
A slightly less
On 01.11.2011 23:55, Brendan Eich wrote:
On Nov 1, 2011, at 11:06 AM, Allen Wirfs-Brock wrote:
On Nov 1, 2011, at 10:57 AM, Brendan Eich wrote:
On Nov 1, 2011, at 10:47 AM, Dmitry Soshnikov wrote:
The technique I showed of course initially is designed to be used with
class-system; though,
For the record: I do think Allen’s design is superior to what I’ve seen so far
and it also most clearly reflects the semantics of |super| (apart from a
non-starter dynamic solution). Sorry for the off-topic contributions, I liked
the puzzle of finding an alternative.
Nope -- I think that
+1
to me, this is far more intuitive than the current proposal.
-Mikeal
On Oct 31, 2011, at October 31, 20116: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
On Mon, Oct 31, 2011 at 9:57 PM, Jeremy Ashkenas jashke...@gmail.comwrote:
'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
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
On 01/11/11 22:18, Brendan Eich wrote:
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
On Nov 1, 2011, at 6:57 PM, Quildreen Motta wrote:
I like how clean the syntax is there, Brendan. I still feel class syntax
would have more value if they presented a nice way for object composition
besides inheritance.
Traits were factored out and I consider adding them in this exercise to
On 02/11/11 00:01, Brendan Eich wrote:
On Nov 1, 2011, at 6:57 PM, Quildreen Motta wrote:
I like how clean the syntax is there, Brendan. I still feel class syntax would
have more value if they presented a nice way for object composition besides
inheritance.
Traits were factored out and I
On Nov 1, 2011, at 7:17 PM, Quildreen Motta wrote:
There's `public', but then, that's quite verbose. I guess people comming from
a classical language with declarative definitions for class slots might still
be used to it, none the less.
I thought of that, but then 'public const'? Muy
On Tue, Nov 1, 2011 at 19:32, Brendan Eich bren...@mozilla.com wrote:
On Nov 1, 2011, at 7:17 PM, Quildreen Motta wrote:
There's `public', but then, that's quite verbose. I guess people comming
from a classical language with declarative definitions for class slots might
still be used to it,
'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.
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 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
86 matches
Mail list logo
