On Tue, May 22, 2012 at 3:11 PM, Herby Vojčík 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 (inten
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 ha
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
>
> 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. I
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
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 lit
>
> 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
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 c
>
> 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,
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 new()/stat
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
>
>
>> 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 w
n the class and reader will
need to switch 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 cl
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 p
>
> 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 prot
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
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 vari
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
>
> 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
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
sticki
On Fri, Apr 6, 2012 at 9:38 PM, Kevin Smith 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 that I'm some
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
es-d
>
> 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 b
On Fri, Apr 6, 2012 at 7:34 PM, Kevin Smith 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 f
>
> 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 cla
On Fri, Apr 6, 2012 at 4:18 PM, Kevin Smith 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 unav
>
> 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.
kevin
___
e
them e.g. in ES.next.next).
On Apr 6, 2012, at 23:10 , Russell Leggett wrote:
> On Fri, Apr 6, 2012 at 4:31 PM, Tab Atkins Jr. wrote:
> On Fri, Apr 6, 2012 at 1:27 PM, Kevin Smith wrote:
> > Looking at Allen's collection classes, it's clear that our maximally mini
On Fri, Apr 6, 2012 at 4:31 PM, Tab Atkins Jr. wrote:
> On Fri, Apr 6, 2012 at 1:27 PM, 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 of the cl
On Fri, Apr 6, 2012 at 1:27 PM, 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 of the classes we
> might want to create. As a general goal, I think that a comple
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
interfa
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
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:
4)
which is hardly something
> we should be pushing for.
Strongly agreed.
I don't have any *particular* 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
figur
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.{ ...
}.constructo
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
> seman
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 meta
On Mar 31, 2012, at 9:54 PM, 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-
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 t
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 use
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,
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:
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 ge
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
Allen,
Thanks for this work - it's definitely helpful to see something concrete.
I agree with Domenic that classes seem to communicate the intent more
purely.
I also think that we're not quite there yet with respect to our class
proposal. We have something that we all (more or less) agree on, s
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
To me, it is amazing how much clearer maximally-minimal classes make this code.
The `<| function(){`, `}.prototype.{`, and `}.constructor.{` incantations in
[4] are almost completely opaque, as is the reason behind needing
`Function.prototype` as the lhs of `<|` for `AbstractClass`. Th
Allen Wirfs-Brock wrote:
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
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 alternati
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?
>
>>
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 = Object.create(proto
(for example) but not an anonymous class - after all
>>> both contain 'class' elements.
>>> If the answer is 'no', it seems like '<|' fragments the ways to define a
>>> class shape where
>>>
>>> LHS <| {
>>>
shape where
>>
>> LHS <| {
>> constructor: function(name,title) {
>> Person.call(this,name);
>> this.title = title;
>> }
>> }
>>
>> works but
>>
>> LHS <| class {
>> constructor(name,title) {
>> pr
t; }
> }
>
> works but
>
> LHS <| class {
> constructor(name,title) {
> private title;
> super(name);
> @title = title;
> }
>
> does not.
>
>
> From: Allen Wirfs-Brock
> To: Russell Leggett
> Cc: Axel Rauschmayer ; es-discuss
> 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 preclu
> 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 wou
>> 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
.title = title;
}
}
works but
LHS <| class {
constructor(name,title) {
private title;
super(name);
@title = title;
}
does not.
From: Allen Wirfs-Brock
To: Russell Leggett
Cc: Axel Rauschmayer ; es-discuss
Sent: Sunday, October 2, 2011 3:19
On Oct 2, 2011, at 8:19 PM, Allen Wirfs-Brock wrote:
>
> On Oct 2, 2011, at 5:02 PM, Russell Leggett wrote:
>
>> On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock wrote:
>>
>>>
>>> Is that the
>>> SuperClass <| {
>>> ...
>>> }
>>> part evaluates to the prototype object, n
On Oct 2, 2011, at 5:02 PM, Russell Leggett wrote:
> On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock wrote:
>
>>>
>>
>> Is that the
>> SuperClass <| {
>> ...
>> }
>> part evaluates to the prototype object, not the constructor function and
>> hence what you would be naming
On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock 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 a deeply
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 th
On Sun, Oct 2, 2011 at 3:52 PM, Allen Wirfs-Brock 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
> "recursive stache" (hey,
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 the other hand, perhaps we could flip the bit the other way, and unify on
> "extend" instead of <|. In scala, the is both a "class" and "object" syntax
> that is kind of similar to the situation we currently have creating objects
> with object literal notation and class literal notation.
I
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
> const ClassName = SuperClass <| {
> constructor(/*constructor parameters */) {
> //constructor body
> super.constructor(/*arguments to super constructor */);
> this.{
>//per instance property definitions
>
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
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 nic
calling superclass method(s)?
>
> I think this is an essential 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
On Mon, Jun 27, 2011 at 10:13 PM, Brendan Eich 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 constructor
>
> But what
>> - 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 sema
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
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 ex
74 matches
Mail list logo