Brendan Eich wrote:
Herby Vojčík wrote:
Let's allow foo.? to denote soft foo, so you get:
foo.?.bar // foo == null ? undefined : foo.bar
foo.?(bar) // foo == null ? undefined : foo(bar)
foo.?[bar] // foo == null ? undefined : foo[bar]
?. works as well for these and the main (by use
Allen Wirfs-Brock wrote:
On Jun 19, 2012, at 12:44 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
This proposal augments the default
operatorhttp://wiki.ecmascript.org/doku.php?id=strawman:default_operator by adding
syntax to avoid accessing a missing property, specifically |?.| for
Brendan Eich wrote:
Jeremy Ashkenas wrote:
Everywhere else in the language, `?` means existence (not null or
undefined) -- but when used to call a function, the check ensures that
the value is callable as well. In a DWIM sense, this makes sense,
because the only things you'd ever want to try
Brendan Eich wrote:
In fact, I don't think I was pushing any particular syntax. I think I
was clear about asking _whether_ people saw value in the semantics of
it, not the syntax. It's fine if people don't see value; is there a
problem with asking the question?
I was describing the hazards
Herby Vojčík wrote:
Brendan Eich wrote:
In fact, I don't think I was pushing any particular syntax. I think I
was clear about asking _whether_ people saw value in the semantics of
it, not the syntax. It's fine if people don't see value; is there a
problem with asking the question?
I
T.J. Crowder wrote:
On 15 June 2012 07:42, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
T.J. Crowder wrote:
Making a point of making this a separate thread from the current
?? and
??= thread(s), which are thankfully looking close to consensus. So
Hi.
I have hard time to put my objections well. Different words appear in my
mind like too monolithic, too spaghetti, ... but none of them is
very good at explaining the problem.
It seems to me that this make thing complex and brittle. Protected
overides writable and configurable, so their
Addition to previous post on aliasProperty: you can only create alias on
configurable property, of course.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Andrea Giammarchi wrote:
just in case ... this is my internal function
// var is = Object.is || properShim
// var indexOf = [].indexOf || shortShim
// var i;
function betterIndexOf(value) {
if (value != value || value === 0) {
for (i = this.length; i-- !is(this[i],
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
While I'm less than enthusiastic about explicitly provided undefined
values triggering default value usages, I don't think it is
particularly harmful. I think treating null equivalently would be.
Noted, but you have not responded to the argument,
Herby Vojčík wrote:
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
While I'm less than enthusiastic about explicitly provided undefined
values triggering default value usages, I don't think it is
particularly harmful. I think treating null equivalently would be.
Noted, but you have
Tab Atkins Jr. wrote:
On Thu, Jun 14, 2012 at 11:01 AM, Brendan Eichbren...@mozilla.com wrote:
We have a problem with || indeed. The question is whether the solution
should equate null and undefined. CoffeeScript chose the
conceal-the-difference path and it has users. The users who want null
Thaddee Tyl wrote:
On Tue, Jun 12, 2012 at 10:17 PM, David Hermandher...@mozilla.com wrote:
On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
My point still stands. Being undefined-specific is arbitrary.
CoffeeScript could have been undefined-specific; they were
undefined + null-specific,
Rick Waldron wrote:
On Tue, Jun 12, 2012 at 10:38 AM, Felix Böhm esdisc...@feedic.com
mailto:esdisc...@feedic.com wrote:
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Consider:
function
Felix Böhm wrote:
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Use-case: Most SQL libraries for node support passing query arguments to
the query function (so SQL injections are avoided). The usual
T.J. Crowder wrote:
On 12 June 2012 16:42, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
But I understand there are problems. First, what with optional
params after ...rest. And the second, how to parse it when foo(1, 2)
called?
I would think with
function foo
Luke Hoban wrote:
In fact, without|, are there any cases where super behaves
correctly in an object literal, other than making super calls to
Object.prototype functions?
We haven't eliminated the ability to define object literals that
inherit from objects other than Object.prototype. We
Allen Wirfs-Brock wrote:
On May 30, 2012, at 4:42 PM, Brendan Eich wrote:
What we agreed to last week: no |super| outside of classes in ES6,
no Object.defineMethod in ES6. That's what I recall and what the
notes say (re: |super|).
I also don't see the mention of defineMethod although I know
Hello,
reacting to super only in classes, I'd like to propose widening it
just a little bit:
1. Allow super in every concise methods (in classes, as well as out of
them).
1a. constructor method in class definition is also rated as concise
method for the purpose of 1.
2. Allow
function
Brendan Eich wrote:
Brendan Eich wrote:
The only usable+secure extensions I see are two, so we don't confuse
users with almost-identical syntax with quite different (when it
matters most, when under attack) semantics:
A. obj.{prop: val, ...} as safe mustache, with : for define not assign.
Brendan Eich wrote:
Herby Vojčík wrote:
.{...} has established ways to do things, like .{0:foo, 1:bar}
(and recently it even had .{[key]:value}).
Established how? Mustache syntax was proposed last July, it's not fully
in Harmony -- hence Allen's new strawman.
By basically saying what
Hello,
to make things more DRY in spec and more consistent, what if
{some_content} in expression context would be defined as syntactic sugar
for (new Object).{some_content}?
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
Brendan Eich wrote:
Herby Vojčík wrote:
Hello,
to make things more DRY in spec and more consistent, what if
{some_content} in expression context would be defined as syntactic
sugar for (new Object).{some_content}?
No! You have just reintroduced the ES3 bug where a rebound or shadowed
Brendan Eich wrote:
Herby Vojčík wrote:
You need (need in the sense having readable construct to perform)
.{...} with [[DefineOwnProperty]] not for foo:bar (yes, there
[[Put]] should happen
No, again: JSON theft attack possible again with [[Put]]. Declarative
syntax is foo: bar. That means
Allen Wirfs-Brock wrote:
On May 24, 2012, at 1:50 PM, Erik Arvidsson wrote:
I think it is impossible to achieve Waldemar's goal with syntactic
sugar only. I also don't think that is reason enough to block ES6
classes. The requirements he wants cannot be expressed with ES5
semantics.
I'm
Tab Atkins Jr. wrote:
On Tue, May 29, 2012 at 9:26 AM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
Thanks for the clarifications. I understand wanting to make the distinction
from an implementer point of view, I'm just not sure that developers make
the distinction between [[Put]]
Couldn't all this be solved by allowing = also for object literals and
promoting its use? People get used to the fact that = is the normal
way and : is the special way plus they are told JSON only has : for
both historical and security reasons.
Because I feel the main problem felt here is
the consistency for this hard-wired)?
Herby
Allen Wirfs-Brock wrote:
On May 29, 2012, at 11:17 AM, Herby Vojčík wrote:
Couldn't all this be solved by allowing = also for object literals
and promoting its use? People get used to the fact that = is the
normal way and : is the special way plus
Rick Waldron wrote:
super
LH:
- This may be too confusing for the common user
AWB:
- Asserts that super is defined correctly for classes
(explanation)
Should super be allowed in all function forms or restricted to classes?
Resolution: Defer super outside of classes
Any chance to get this
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
Luke Hoban wrote:
On May 22, 2012, at 9:29 AM, Erik Arvidsson wrote:
I think this proposal has one fatal flaw and that was what brought it
down the last time we had a proposal which used the same concepts.
Given:
class C(x) {
public method() {
return x;
}
}
It seems like the
Luke Hoban wrote:
Herby Vojčíkhe...@mailbox.sk wrote:
I just don't understand why you use class keyword here. This will
work without any changes, as-is, with plain function keyword. After
all, you just augment a constructor definition.
The body of this kind of function is different, in
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
Axel Rauschmayer wrote:
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it takes
any x and tells whether x is an Array (from any window or frame)
instance, it should have gone on object.
Allen Wirfs-Brock wrote:
On May 9, 2012, at 4:08 PM, Axel Rauschmayer wrote:
Are we going to have RegExp.isRegExp() and Date.isDate() and
Number.isNumber() etc. too ?
I did wince a bit about ES5's Array.isArray -- perhaps since it
takes any x and tells whether x is an Array (from any window
Brendan Eich wrote:
John J Barton wrote:
On Wed, May 9, 2012 at 2:22 PM, Brendan Eichbren...@mozilla.org wrote:
As Crock said, the problem programmers face is I have a value, I
want to
treat it as an object and get a property (call a method, etc.). How do I
test is-this-an-object so that I
Wes Garland wrote:
It looks to me like this code would work just fine by removing the word
'typeof'. What am I missing?
Cross-frame/cross-context, too?
On 8 May 2012 12:19, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
module Foo {
export function
Andreas Rossberg wrote:
On 21 April 2012 01:22, Allen Wirfs-Brockal...@wirfs-brock.com wrote:
7) All of the above questions also apply to functions defined using concise
method syntax in object literals or classes. Should the same answers apply to
them?
I'd prefer if concise method syntax
Andreas Rossberg wrote:
On 21 April 2012 01:08, Brendan Eichbren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
What I'm really pushing at here is the throw. Let's are used for
establishing and initializing bindings. From a binding perspective:
let x ;
and
let {x} = {};
are
David Nolen wrote:
On Wed, Apr 18, 2012 at 11:26 AM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
We've supported destructuring for years and no one has asked for
this. I say YAGNI and when in doubt, leave it out. One can always
write two destructuring
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out of the box (in
FF11 firebug console; just tried), so why include as if it already
Andreas Rossberg wrote:
On 18 April 2012 17:51, Herby Vojčíkhe...@mailbox.sk wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
That won't work for arrays, for example.
Yeah. :-/
Then either not have it or syntax
Allen Wirfs-Brock wrote:
On Apr 18, 2012, at 9:29 AM, Brendan Eich wrote:
Herby Vojčík wrote:
Herby Vojčík wrote:
Maybe allowing
let {b, b:{x,y}} = obj;
would be enough. It sort-of comforms to existing syntax as well as
semantics.
BTW, if you use var instead of let, if already works out
Herby Vojčík wrote:
But, AFAICT, this should be allowed. The 'b:' from destructuring is
Sorry for caps, I don't know why I write it that way... I somehow
automatically held shift because it is an acronym, probably.
___
es-discuss mailing list
es
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
For array patterns we would need to allow property assignments in
array literals:
let [b, 0:{x,y}] = ...;
This was proposed at one point, IIRC, but a while ago.
Of course, one could destructure like so:
let {0: b, 0: {x, y}} = ...;
It was
Brendan Eich wrote:
Herby Vojčík wrote:
As was already pointed out, problems are not only _array_
destructurings, but more argument list destructrings, where if you
want to destructure 0-th argument both as b and as {x,y}, you would
need something like that, since you already are inside list
Andreas Rossberg wrote:
On 3 April 2012 22:16, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
foo(a, b, ...rest)
vs
foo(a, b, rest...)
Which is clearer?
First, because it is much more apparent that 'rest' is a different beast
than the other
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
Hello,
this is more a conceptual question post. But first some proposals that
circulated in the list:
1. Dynamic-this enabled fat arrow functions.
(this, ...) = expr
(this, ...) = { body }
2. ABC (apply/bind/call) shortcuts.
thisobj::identifier(...args) // apply
thisobj::identifier // bind
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
Angus Croll wrote:
On Fri, Mar 30, 2012 at 4:46 AM, Felix Böhm esdisc...@feedic.com
mailto:esdisc...@feedic.com wrote:
How about a loose-bound |this|, so that the function falls back to
the bound |this| instead of the global scope when no other options
are available (or `null` or
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
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.
Only things that bothers me a bit (except the inconsistent new keyword)
is the potential ambiguity - I can add method to body, but
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
But you should want to do that renaming because the helper is no
longer a method so making it a function that references this would
just be a likely source of confusion concerning the intended use of
the function
IOW, OOP-uber-alles does not work
Brendan Eich wrote:
Russell Leggett wrote:
And would result in copying all of the properties from myMixin into
the object literal.
Including the private-named properties? That would be bad for integrity:
Alice can't give Bob an object-as-capability where the private names
stay private. Bob
let obj = { a:2, b:4, prop(c, 6), counter() };
class Foo {
constructor(x) { this.{ prop(x, x) } }
counter()
}
let obj = { a:2, b:4, prop(c, 6), counter() };
class Foo {
constructor(x) { this.{ prop(x, x) } }
counter();
}
semicolon missed
Brendan Eich wrote:
Claus Reinke wrote:
And I was surprised that both pro and cons camps continued the
discussion of recursive self and dynamic this naming as if no
workaround was available.
I don't think anyone is really pushing hard for a dynamic-|this| form
(say, -) right now. Perhaps
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
Claus Reinke wrote:
Module syntax alternatives:
module x at foo.js
module x = foo.js
module foo.js as x
module x at foo.js
module x from foo.js
module x foo.js
Claus
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
Brendan Eich wrote:
Kevin Smith wrote:
I hate the CoffeeScript deviation, though. It's just confusing for
anyone who ever learned that fat-arrow binds |this| and thin-arrow
doesn't.
True. On the other hand, all arrows bind |this| is also quite simple
and easy to remember.
Yes, and I kept
Domenic Denicola wrote:
On Mar 27, 2012, at 13:10, David Hermandher...@mozilla.com
wrote:
I recognize the C.prototype.constructor idiom already exists, but
it's a weak idiom. I'm not crazy about the idea of strengthening a
problematic but currently unreliable and rarely used idiom.
Dave
Somehow, this did not get into the list, so I am resending it...
hopefully it won't get duplicated.
Original Message
From: Herby Vojčík he...@mailbox.sk
Subject: Setting inheritance chains, |, extends, class and all the stuff
Date: Wed, 21 Mar 2012 18:58:59 +0100
Andreas Rossberg wrote:
On 23 March 2012 08:42, Claus Reinke claus.rei...@talk21.com
mailto:claus.rei...@talk21.com wrote:
- would it make sense to name the constructor after the class
(avoiding 'constructor' and 'new')?
-1.
I always considered this a bad choice of C++-derived
Russell Leggett wrote:
On Fri, Mar 23, 2012 at 7:00 AM, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
I will repeat myself, I proposed this thing but no one reacted. It's
short, does not clash as new mentioned before, and does not preclude
constuctor magic in any way
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it
in the first place, since he felt programmers would get confused that
it was a
Allen Wirfs-Brock wrote:
We can live quite nicely with treating class declaration like const
declarations. The name is logically hoisted so it is visible over the
lexical scope, but the name is temporally dead until the class
declaration is executed, in statement sequence, as an initializer.
David Herman wrote:
On Mar 20, 2012, at 6:59 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2012, at 11:55 AM, David Herman wrote:
My only syntactic quibble: `constructor` is so inconveniently long.
I've argued in the past for `new` as special syntax in class bodies
that indicates a constructor.
Yeah, they are pushing it hardly this way. It seems inevitable...
I am willing to accept it, but I'd like to have a clear mapping from
object initializer components into class body components - if it is
there, I don't care about syntax (the main concern for me is, that if
certain things are
Axel Rauschmayer wrote:
On Mar 21, 2012, at 12:42 , Herby Vojčík wrote:
Yeah, they are pushing it hardly this way. It seems inevitable...
I am willing to accept it, but I'd like to have a clear mapping from
object initializer components into class body components - if it is
there, I don't
Brendan Eich wrote:
Herby Vojčík wrote:
That brings the question: what about static block? I think it should
have exactly same rules as the basic class block (sans possibility
having its own nested static block). That is, what about that const?
Is data allowed in static (const-only or let
John J Barton wrote:
On Wed, Mar 21, 2012 at 11:52 AM, Russell Leggett
russell.legg...@gmail.com wrote:
On Wed, Mar 21, 2012 at 2:47 PM, Allen Wirfs-Brockal...@wirfs-brock.com
wrote:
On Mar 21, 2012, at 8:41 AM, Russell Leggett wrote:
On Wed, Mar 21, 2012 at 11:12 AM, Kevin
David Herman wrote:
I had a great conversation today with my colleagues Michael Bebenita
and Shu-Yu Guo, and we came up with what I think is a nicely
conservative way to add new kinds of numbers to JS without breaking
the intuition that JS has only one type of primitive numbers.
tl;dr: Pure,
Andreas Rossberg wrote:
On 19 March 2012 21:13, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
(Yet Another Wacky Syntax Idea)
Here is a relatively common coding pattern:
var a;
var obj = {
get a() {return a},
set a(v) {a=v}
};
Allen Wirfs-Brock wrote:
(Yet Another Wacky Syntax Idea)
Here is a relatively common coding pattern:
var a;
var obj = {
get a() {return a},
set a(v) {a=v}
};
And why not this (specific to object literals, but they are primary
concern):
let obj = {
let a, // could be 'let a:
Andreas Rossberg wrote:
On 20 March 2012 11:14, Herby Vojčík he...@mailbox.sk
Or let. We may allow let have object literals in list of assignments
and return the last item. So local var for obj literal scenario
could be:
let obj = do {
let a, {
get
Russell Leggett wrote:
Is it possible that we can come up with a class syntax that we can all
agree is better than nothing, and importantly, leaves possibilities open
for future enhancement? As a “safety syntax” this doesn’t mean we stop
trying to find a better syntax, it just means that if we
David Herman wrote:
I can mostly dig it -- I've been trying to encourage minimal classes for
quite some time now.
The part that I'm least happy about is that this doesn't allow for
declarative private methods, because if we had the computed syntax like
what we're adding to object literals, it
Russell Leggett wrote:
On Tue, Mar 20, 2012 at 2:55 PM, David Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
Yes, I debated about this. In fact, I almost did go with new.
Personally, I'm fine with either. I think what swung me in favor of
constructor was:
* other people seem to
Russell Leggett wrote:
We would have to decide what happens if they don't supply a constructor.
I think we would need a default, and in my mind there are 3 possibilities:
1. Empty constructor - does nothing.
2. Calls super with no args
3. Calls super as a pass through
I'm fond of 3,
Allen Wirfs-Brock wrote:
(Yet Another Wacky Syntax Idea)
Here is a relatively common coding pattern:
var a;
var obj = {
get a() {return a},
set a(v) {a=v}
};
Often the intent is that the variable a should only be used within the object
literal. The block scoping with let and do
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 1:20 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
This has nothing to do with classes. It is just basic prototypal
inheritance and the semantics of the new operator and function
expressions.
Well, seems convincing... but nevertheless, I see
Kevin Smith wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
The point I'm trying to drive home is that the above is no better
(worse, in fact) from a user experience standpoint, than what I have
now.
Claus Reinke wrote:
var Blah = BaseClass | function(){}
Blah.prototype.{
a: function(){},
b: function(){}
}
let Blah = BaseClass | function() {
}.prototype.(
a() {},
b() {}
}.constructor.{};
1. I don't like the imperative approximations of a declarative API.
Since we're designing new
Isn't it used in E4X (not that I used it or care for it; but I recall I
have read somewhere :: is not usable for this reason... I would
otherwise proposed it already ;-) )?
Herby
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using : instead of |,
Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and to avoid the special case for function rhs, ie, to
Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 8:39 AM, Claus Reinke wrote:
1. I don't like the imperative approximations of a declarative API.
Since we're designing new language features, approximations
should not be necessary.
There have been suggestions to interpret '|' declaratively,
and
Number.prototype.toHexExponential
This is similar to 'toExponential' but is in the normalised hexadecimal
form instead of decimal.
E.g. 1.4A2p+4
The letter 'p' corresponds to decimal's 'e', and means times 2 to the
power of.
The *binary* exponent is represented in signed *decimal*.
The hex
François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intuitive and
easier to type
let A as Number = 3;
let B as Email = x...@google.com;
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
However, it is'nt a reserved keyword. But I don't think
Brendan Eich wrote:
Herby Vojčík wrote:
I am probably writing densely and you had little time. I have written
at the beginning of 1.:
'class ...}' as a sugar for 'function ...}.prototype'
(I put similar texts describing the idea to the header of 2. and 3. as
well)
I get
Kevin Smith wrote:
Rather than abuse your inbox, I published this as a blog entry:
http://blog.khs4473.com/2012/03/using-object-literals-as-classes.html
Summary: It has been suggested that extended object literals can be
used to define class-like abstractions, and that consequently class
Axel Rauschmayer wrote:
Can we make progress on the class declaration front (important for
usability and tool support)?
What is the current state with regard to the objections against an
Ashkenas-style (or Herman-style) minimal solution (that is: mostly
object initializer syntax, prefixed by
David Bruant wrote:
Le 16/03/2012 17:53, Herby Vojčík a écrit :
And second, it is not a tragedy if such classes leak.
What do you mean exactly by leak. Like private name leaking?
Some of the underlying mechanics.
David
___
es-discuss mailing
Domenic Denicola wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype
methods at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g.
by
Brendan Eich wrote:
I noted to Jeremy that even his classes gist snuck in a novelty or two
(the one I remember is class expr evaluating expr and copying it
somehow). We need to avoid novelty, while accepting that doing so is to
some extent future-hostile because present-friendly.
Could you
Kevin Smith wrote:
That’s why I’m not sure that mixing the two styles is a good idea.
I agree. I'm not a CS user and I personally prefer C-ish syntax, but
I'm perfectly willing to steal ideas that might work.
I'm still hoping that ES.next includes declarative classes, and
according to
Brendan Eich wrote:
Definitely, but classes have bigger issues than private syntax, and have
for a while. Class-side inheritance, body syntax, whether there should
be any declarative public syntax, what nested classes mean, static or
'class' members -- that's a partial list from memory.
Minimal
Sorry for the strange subject, I have written
object literal based class too minimal? (was: Re: @name)
but Postbox Express somehow ate it.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich wrote:
Herby Vojčík wrote:
Brendan Eich wrote:
Definitely, but classes have bigger issues than private syntax, and have
for a while. Class-side inheritance, body syntax, whether there should
be any declarative public syntax, what nested classes mean, static or
'class' members
Brendan Eich wrote:
That is coherent with new Foo - 'Foo is the class' means 'new Foo
returns new instance'.
Yes, but your first example, class List(n) {...} cited above at the very
top, uses .{ to add what looks like prototype methods at and size. If
class List(n){...} evaluates to the
201 - 300 of 461 matches
Mail list logo
