Luke Hoban wrote:
In the discussion of max/min classes at the March TC39 meeting, there
was support for minimal class syntax, but a couple concerns with
max/min classes in particular.
One category of concern is the (intentional) bare-bones nature of
max/min. In this case though, I think it
On Tue, May 22, 2012 at 3:11 PM, Herby Vojčík he...@mailbox.sk wrote:
Luke Hoban wrote:
In the discussion of max/min classes at the March TC39 meeting, there
was support for minimal class syntax, but a couple concerns with
max/min classes in particular.
One category of concern is the
Kevin Smith wrote:
I always disliked that some functions in ECMAScript 5 can be invoked
as either a function or a constructor. What would you want an entity
Foo for that can be invoked in two ways? E.g.:
new Foo(...)
Foo(...)
My answer to this is probably a
I think separating [[Call]] and [[Construct]] to different bodies might be
a good idea. But to preserve flexibility, I also think that if you do
MyClass.call(Object.create(MyClass.prototype));
it should call the [[Construct]]. i.e. if it should use [[Construct]] when
'this' is an instance of the
MyClass.call(Object.create(MyClass.prototype));
it should call the [[Construct]]. i.e. if it should use [[Construct]] when
'this' is an instance of the class (inherits from it's prototype).
Of course, the above is equivalent to just new MyClass(...) (I think),
but I see your point. It may
On Apr 7, 2012, at 1:17 PM, Herby Vojčík wrote:
I have actually looked at the links (I confess I did not want to browse
though another way to ruin (nearly a) consensus on max-min), and I must admit
I like it.
My reaction to Kevin's initial post was much the same as Herby's. I'm just not
Kevin Smith wrote:
I like your new(){}/static(){} idea at a glance. Need to ruminate
(moo!) on it at length.
I can't give you a use case (it's just a felling of being a good design
thing), but I would like the classes be higher-level construct based on
low-level ones. If
I can't give you a use case (it's just a felling of being a good design
thing), but I would like the classes be higher-level construct based on
low-level ones. If new()/static() gets in, it defines its own exclusive
semantics not possible to do by plain constructor
I agree in general, but
But isn’t a clear separation of responsibility better?
Want a constructor = use a class declaration.
Want a callable = use an arrow function.
I always disliked that some functions in ECMAScript 5 can be invoked as either
a function or a constructor. What would you want an entity Foo for that
I always disliked that some functions in ECMAScript 5 can be invoked as
either a function or a constructor. What would you want an entity Foo for
that can be invoked in two ways? E.g.:
new Foo(...)
Foo(...)
Maybe Brendan can answer that one? : )
Seriously, though, it's a fair
Brendan Eich wrote:
I like Kevin's gist and want a private declaration too, both on its own
(block-scoped so private foo is const foo = new Name('foo')) and as a
special form in a class body, for body-scoped (fresh Name per class
expression or declaration evaluation) class-private instance
Kevin Smith wrote:
Arbitrary prototype properties is surely to draw fire. It can be a
foot-gun and might conflict with instance properties in the future.
Foot gun: yes. I've shot myself in the foot with it. But I think it
can be addressed in a way that's footgun-proof. We're going
Why? I mean, what built-in in ECMA-262 or a DOM spec needs non-method data
properties? Methods and accessors, yes. Constants go on the constructor.
I'm probably forgetting some bogus Java-like WebIDL binding rule here...
The Event constants (AT_TARGET, etc.) are defined on the Event
Kevin Smith wrote:
The Event constants (AT_TARGET, etc.) are defined on the Event
prototype (as well as on the constructor).
Java hold-over, I think (class statics are available on instances, IIRC).
Another use case, mentioned by Dave, would be adding generic methods
defined elsewhere to the
PoV if reading one from the opposite school.
Otherwise, nice (again, if prototype/static are full-blown object
initialziers).
Herby
Kevin Smith wrote:
Looking at Allen's collection classes, it's clear that our maximally
minimal classes aren't sufficient for describing a large subset
I like your new(){}/static(){} idea at a glance. Need to ruminate (moo!)
on it at length.
Some details:
- Clearly super() would have to call the [[Construct]] behavior: new() {}.
- If there were a different number of formal parameters for the two, what
would MyClass.length be?
- What would
Hi Herby,
Thanks for taking a look!
Only things that bothers me a bit (except the inconsistent new keyword) is
the potential ambiguity - I can add method to body, but (since I presume
prototype and static block and fully-blown object initializers (if not, I
take it back and I do not like
Looking at Allen's collection classes, it's clear that our maximally
minimal classes aren't sufficient for describing a large subset of the
classes we might want to create. As a general goal, I think that a
complete class syntax should be able to express all of the external
interface of the class
On Fri, Apr 6, 2012 at 4:31 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Apr 6, 2012 at 1:27 PM, Kevin Smith khs4...@gmail.com wrote:
Looking at Allen's collection classes, it's clear that our maximally
minimal
classes aren't sufficient for describing a large subset of the classes
minimal
classes aren't sufficient for describing a large subset of the classes we
might want to create. As a general goal, I think that a complete class
syntax should be able to express all of the external interface of the class,
for all except a small set of edge cases.
A complete class
On Fri, Apr 6, 2012 at 4:18 PM, Kevin Smith khs4...@gmail.com wrote:
A complete class syntax, yes. Maximally-minimal classes aren't
attempting to be a complete class syntax.
Then they are half-baked and non ready for inclusion in a mature language.
This conclusion is unavoidable
Again, the entire point of maximally-minimal classes was to be as
simple as possible while still providing something useful (which they
succeeded at), and to remain friendly to becoming more complicated in
the future (also succeeded!).
Even if maximally minimal classes could make
On Fri, Apr 6, 2012 at 7:34 PM, Kevin Smith khs4...@gmail.com wrote:
Again, the entire point of maximally-minimal classes was to be as
simple as possible while still providing something useful (which they
succeeded at), and to remain friendly to becoming more complicated in
the future (also
What you're missing is the history.
Russell, that's not fair. I've been listening for quite a while and I've
combed through the archives. I've poured over each of the proposals that
you've mentioned. You're assuming that I'm some kind of newbie because I
dissent?
I knew this post might be
Back to the point:
Forget about syntax details - I posted a possible syntax, but it could be
anything. Do you disagree that at least the first three items in my
original post should be in any complete class syntax?
kevin
___
es-discuss mailing list
On Fri, Apr 6, 2012 at 9:38 PM, Kevin Smith khs4...@gmail.com wrote:
What you're missing is the history.
Russell, that's not fair. I've been listening for quite a while and I've
combed through the archives. I've poured over each of the proposals that
you've mentioned. You're assuming
Russell Leggett wrote:
However, that means if we take out arbitrary prototype properties,
we're back to a proposal which also hasn't reached consensus.
No proposal has. It's possible we'll get there either way, what is in
max-min or in Kevin's gists (not far off). Neither addresses the
I'm not assuming you're a newbie. Heck, I consider myself a
newbie. Perhaps I'm just jaded. Two weeks ago, I had hope that max-min
would get us something. Now I'm feeling less hopeful.
No way - we're gonna get classes in. : )
Arbitrary prototype properties is surely to draw fire. It can
Kevin Smith wrote:
Arbitrary prototype properties is surely to draw fire. It can be a
foot-gun and might conflict with instance properties in the future.
Foot gun: yes. I've shot myself in the foot with it. But I think it
can be addressed in a way that's footgun-proof. We're going
On Apr 2, 2012, at 5:00 PM, John J Barton wrote:
Allen's original post on this thread offered two choices:
1) extended object literals, (good building blocks).
2) both, (because class gives 80% and thus they complement).
Erik and Tab are arguing for
3) Min-max classes (we need 80%,
The main issue you will see if you do user studies on people trying to
do OOP in JS is that the way to set up the prototype chain in ES3/5 is
too hard. There is a reason why almost all JS libraries add ways to
make this easier.
With the let C = B | function() { ... }.prototype.{ ...
}.constructor
* problem with the current ES3-style
classes, except that they're verbose to write and difficult to read.
Their structure doesn't *speak* to you when reading it; you have to
figure out for yourself what the right pattern is and how to recognize
it in code.
The maximal-minimal classes fix
Allen's original post on this thread offered two choices:
1) extended object literals, (good building blocks).
2) both, (because class gives 80% and thus they complement).
Erik and Tab are arguing for
3) Min-max classes (we need 80%, not building blocks).
The current winner no one wants:
Russell Leggett wrote:
When I started the Safety Syntax thread which let to the max-min
proposal, I really did hope that we would still be able to slip some
more features in for ES6, I just wanted to make sure we had *something*,
even if it had to be max-min. I wanted to try to start with a
Hi Russ,
We can see from the examples that Allen posted that two features are used
in virtually every class definition: a mechanism for carrying private
instance state, and properties attached to the constructor itself (static
members, if you'll pardon the misnomer).
I'm currently thinking that
Allen Wirfs-Brock wrote:
However, when we add private as a ClassElement we have crossed the line to
having things other PropertyMethodDefinition in ClassBody. If this opens the
flood gates for every over possible addition we will be back in the swamp.
I like your message, except for this
On Apr 1, 2012, at 2:58 AM, Herby Vojčík wrote:
...
Max-min classes were presented as the thing that does not prevent class
evolution in more object-initializer-like-way (it is already unfriendly in
making it object-initializer-syntactically bercause of comma-elision, but
semantically
At the recent TC39 meeting a couple people raised the concern that maximally
minimal class definitions [1] don't really do anything that isn't also possible
with enhanced object literals [2] and hence the additional complexity they add
to the language is undesirable. Only one of these
As a quick follow-up:
Perhaps adding non-arcane-incantation private name declarations would be enough
to push maximally-minimal classes from “nice, but are they worth it?” to “this
gives us something we can’t get anywhere else.” To wit:
class Set extends Collection {
private setContents
On Mar 31, 2012, at 19:40 , Allen Wirfs-Brock wrote:
Even though max-min classes don't have all possible class bells and whistles
they are a good 80% solution that will likely to widely used and will
facilitate code usage that crosses developer and library boundaries.
That, to me, is the
On Mar 31, 2012, at 5:19 PM, Domenic Denicola wrote:
As a quick follow-up:
Perhaps adding non-arcane-incantation private name declarations would be
enough to push maximally-minimal classes from “nice, but are they worth it?”
to “this gives us something we can’t get anywhere else.” To wit
Why would it go outside? Because we don't allow it inside is not the
reason, I hope.
It would be better -- if it were not a friend private among classes --
to put it in the class body (which again has custom syntax, neither
object literal nor function body).
/be
Allen Wirfs-Brock wrote:
When I started the Safety Syntax thread which let to the max-min
proposal, I really did hope that we would still be able to slip some more
features in for ES6, I just wanted to make sure we had *something*, even if
it had to be max-min. I wanted to try to start with a useful baseline as
fallback,
extension to Set Literal Prototype operator as minimal
classes
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
I can see the recursive stache useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability to apply a deeply nested patch
What distinguishes it is that I was adding a new case to | operator where
the LHS is a constructor function and the RHS is an object literal. My
intention was that SuperClass would be the constructor function not a
prototype. Perhaps this is confusing because the return type is not the same
const Person = Mammal | {
name: 'John Doe',
constructor(sex,name) {
super.constructor(sex);
this.{name}
}
}
console.log(typeof Person); //'object', not 'function'
console.log(Person.name); //'John Doe'
Person is the prototypal person. You would then
Your last requirement is the rub. As currently defined,
prototype: { ...}
would replace the value of the constructor's 'prototype' property which would
mess up the implicit constructor/prototype wiring. Defining : to mean .{ if
the property already exists seems fragile and precludes
Subject: Re: Minor extension to Set Literal Prototype operator as minimal
classes
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
I can see the recursive stache useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability
Prototype operator as minimal
classes
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
I can see the recursive stache useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability to apply a deeply nested patch to an object, which
Addendum: With the definition of the new operator as below (for non-function
operands, if the operand is a function, things stay the same), do you think a
reference from Person.constructor.prototype to Person is still necessary?
operator new(proto, ...args) {
let o =
On Oct 3, 2011, at 4:19 AM, Axel Rauschmayer wrote:
Addendum: With the definition of the new operator as below (for non-function
operands, if the operand is a function, things stay the same), do you think a
reference from Person.constructor.prototype to Person is still necessary?
On Oct 1, 2011, at 8:23 PM, Axel Rauschmayer wrote:
...
What do you think about the following variation of Allen’s pattern?
const ClassName = SuperClass | function(/*constructor parameters */) {
//constructor body
super.constructor(/*arguments to super constructor */);
On Sun, Oct 2, 2011 at 3:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It's only a one character change but it eliminates the hazard that some
people are concerned about of leaving off the .constructor or
.constructor.{...} at the end of the pattern. Also, I can imagine that
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
I can see the recursive stache useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability to apply a deeply nested patch to an object, which is
sort of interesting to think
On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
I can see the recursive stache useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability to apply
On Oct 2, 2011, at 5:02 PM, Russell Leggett wrote:
On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Is that the
SuperClass | {
...
}
part evaluates to the prototype object, not the constructor function and
hence what you would be
On Oct 2, 2011, at 8:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 2, 2011, at 5:02 PM, Russell Leggett wrote:
On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Is that the
SuperClass | {
...
}
part evaluates to the
I'm probably not the first to have thought of this, but it seemed like
the most minimal class support I could think of, and it sounds like
that's where things are headed from the lack of agreement. Through the
additions made by the Set Literal Prototype operator proposal, I think
you nailed 90% of
const ClassName = SuperClass | {
constructor(/*constructor parameters */) {
//constructor body
super.constructor(/*arguments to super constructor */);
this.{
//per instance property definitions
I'm not opposed to the class literal as much as I was trying to think of the
most minimal classes that could find some consensus. It seems from the
discussion that if no syntax can be agreed on, then perhaps it would have to
wait for ES.next.next.
The problem with the class literal syntax
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
I've been concerned about the schedule risk of classes for ES.next; following
are some thoughts about a minimal class feature that I believe satisfies the
most important needs while leaving room for future growth.
I think the bare-minimum requirements of classes would be:
- declarative class
On Jun 27, 2011, at 10:00 PM, David Herman wrote:
- standardizing prototype hierarchies (I'm of the opinion that superclass
constructors ought to be the prototype of subclass constructors in order to
inherit class properties)
+1
- providing idiomatic syntax for calling the superclass
- providing idiomatic syntax for calling the superclass constructor
But what about subclass method calling superclass method(s)?
In terms of priorities, I think super-constructors are the single most
important use case for super. But I think super-methods fall out naturally from
the
On Mon, Jun 27, 2011 at 10:13 PM, Brendan Eich bren...@mozilla.com wrote:
On Jun 27, 2011, at 10:00 PM, David Herman wrote:
I've been concerned about the schedule risk of classes for ES.next
Is the timeline posted somewhere?
- providing idiomatic syntax for calling the superclass
feature for a class syntax. Calling super
for methods is one of the features that JavaScript libraries
prioritize very highly. They all have some way of calling super for a
method.
I agree that the most minimal classes proposal must allow method
super-chaining, not just constructor super-chaining
66 matches
Mail list logo
