On Thu, Sep 29, 2011 at 3:43 AM, Quildreen Motta quildr...@gmail.com wrote:
I'm not sure how this is much different from the rules you have now with
ASI, though if this were such a problem, a block statement could be required
I'm trying to make sure we don't add another feature that we'll later
On Thu, Sep 29, 2011 at 12:13 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Sep 29, 2011 at 12:09 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Sep 28, 2011 at 11:05 PM, Dean Landolt d...@deanlandolt.comwrote:
On Wed, Sep 28, 2011 at 10:06 PM, Mike Shaver
On Wed, Sep 28, 2011 at 10:40 PM, Oliver Hunt oli...@apple.com wrote:
Given our apparent desire to have a declarative syntax i don't see why
something akin to:
class Foo {
var bar; // default value - undefined
var wibble = 5; // initialised fields desugar to statements at the head
On Sep 29, 2011, at 3:20 PM, Russell Leggett wrote:
On Wed, Sep 28, 2011 at 10:40 PM, Oliver Hunt oli...@apple.com wrote:
Given our apparent desire to have a declarative syntax i don't see why
something akin to:
class Foo {
var bar; // default value - undefined
var wibble = 5; //
On Sep 29, 2011, at 9:06 AM, Peter van der Zee wrote:
What you could do here is require paren-less headers to be single
lined, on the same line as the `if` keyword, and require a newline
between the paren-less header and the body. Such newline would signify
the end of the statement header,
On Sep 29, 2011, at 7:52 AM, Brendan Eich wrote:
On Sep 29, 2011, at 3:20 PM, Russell Leggett wrote:
On Wed, Sep 28, 2011 at 10:40 PM, Oliver Hunt oli...@apple.com wrote:
Given our apparent desire to have a declarative syntax i don't see why
something akin to:
Hi, just a voice from
2011/9/29 Peter van der Zee e...@qfox.nl
On Thu, Sep 29, 2011 at 3:43 AM, Quildreen Motta quildr...@gmail.com
wrote:
I'm not sure how this is much different from the rules you have now with
ASI, though if this were such a problem, a block statement could be
required
I'm trying to make
On Sep 28, 2011, at 7:40 PM, Oliver Hunt wrote:
class Foo {
var bar; // default value - undefined
var wibble = 5; // initialised fields desugar to statements at the head of
the constructor
const wiffle; // read barrier on uninitialised
But note that such read barriers must be
On Sep 29, 2011, at 4:47 PM, Oliver Hunt wrote:
There are some on the committee who object to 'var' in particular; others
object to using scoped binding forms to define properties in (default
mutable) objects. We can go around this block again, though.
The exact token isn't overly
On Sep 29, 2011, at 5:41 PM, Allen Wirfs-Brock wrote:
Presumably the job of the constructor is to establish invariants of the
constructed instances. Some of those invariants may involve complex
relationships among property values and between the new object and other
objects. There are many
On Sep 29, 2011, at 6:04 AM, Dean Landolt wrote:
On Thu, Sep 29, 2011 at 12:13 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Thu, Sep 29, 2011 at 12:09 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Sep 28, 2011 at 11:05 PM, Dean Landolt d...@deanlandolt.com wrote:
On Sep 29, 2011, at 9:41 AM, Allen Wirfs-Brock wrote:
On Sep 28, 2011, at 7:40 PM, Oliver Hunt wrote:
class Foo {
var bar; // default value - undefined
var wibble = 5; // initialised fields desugar to statements at the head of
the constructor
const wiffle; // read barrier on
On Sep 29, 2011, at 6:06 PM, Oliver Hunt wrote:
I'm not too concerned about the read barrier -- in terms of runtime cost i a)
don't believe it would be something that people actually use :D, b) even if
they did use it would be sufficiently uncommon to make the perf cost of a
read barrier
On Sep 29, 2011, at 9:59 AM, Brendan Eich wrote:
On Sep 29, 2011, at 4:47 PM, Oliver Hunt wrote:
There are some on the committee who object to 'var' in particular; others
object to using scoped binding forms to define properties in (default
mutable) objects. We can go around this block
On Sep 29, 2011, at 6:14 PM, Oliver Hunt wrote:
On Sep 29, 2011, at 9:59 AM, Brendan Eich wrote:
On Sep 29, 2011, at 4:47 PM, Oliver Hunt wrote:
There are some on the committee who object to 'var' in particular; others
object to using scoped binding forms to define properties in (default
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize __proto__ in Annex B?
MarkM + a few others: Yes
Waldemar, Doug: No
Unless we have a definite plan that no ES.Next impl will support
__proto__, then by all means don't standardize it. However, seeming the
conclusion before was
Sorry to drag on about array holes, but:
Should holes in spread elements (e.g. [...holeyArray]) and arguments
(e.g. f(...holeyArray)) reflect as holes in the array they are spliced
into to avoid information loss ? The current proposal [1] reflects
them as `undefined` values.
Spread arguments
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize __proto__ in Annex B?
MarkM + a few others: Yes
Waldemar, Doug: No
Unless we have a definite plan that no ES.Next impl will support __proto__,
then by all means don't
On 29/09/11 19:10, Brendan Eich wrote:
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize __proto__ in Annex B?
MarkM + a few others: Yes
Waldemar, Doug: No
Unless we have a definite plan that no ES.Next impl will support
On Sep 29, 2011, at 11:07 AM, Sean Eagan wrote:
Sorry to drag on about array holes, but:
Should holes in spread elements (e.g. [...holeyArray]) and arguments
(e.g. f(...holeyArray)) reflect as holes in the array they are spliced
into to avoid information loss ? The current proposal [1]
Le 29/09/2011 20:10, Brendan Eich a écrit :
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize __proto__ in Annex B?
MarkM + a few others: Yes
Waldemar, Doug: No
Unless we have a definite plan that no ES.Next impl will
On Sep 29, 2011, at 10:10 AM, Brendan Eich wrote:
On Sep 29, 2011, at 6:06 PM, Oliver Hunt wrote:
I'm not too concerned about the read barrier -- in terms of runtime cost i
a) don't believe it would be something that people actually use :D, b) even
if they did use it would be
On Sep 29, 2011, at 7:34 PM, David Bruant wrote:
Le 29/09/2011 20:10, Brendan Eich a écrit :
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize __proto__ in Annex B?
MarkM + a few others: Yes
Waldemar, Doug: No
Unless we
On Sep 29, 2011, at 7:46 PM, Allen Wirfs-Brock wrote:
Just pointing out that not using const properties doesn't mean that the need
for a const read barrier on every property access. Without doing closed world
whole program analysis every property [[Get]] has to account for the
possibility
It is a standard (de-facto), we were just talking about making a
non-mandatory normative spec for it. That does carry some weight but
not much more than the de-facto standard, IMHO.
A non-mandatory normative spec, like that of String#substr (even
though JScript implementation is diff) would
On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Sep 29, 2011, at 11:07 AM, Sean Eagan wrote:
Sorry to drag on about array holes, but:
Should holes in spread elements (e.g. [...holeyArray]) and arguments
(e.g. f(...holeyArray)) reflect as holes in the array
On Thu, Sep 29, 2011 at 1:03 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Sep 29, 2011, at 6:04 AM, Dean Landolt wrote:
On Thu, Sep 29, 2011 at 12:13 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Sep 29, 2011 at 12:09 AM, Rick Waldron waldron.r...@gmail.comwrote:
On
On Mon, Sep 26, 2011 at 7:27 PM, Waldemar Horwat walde...@google.com wrote:
Reached consensus on the following # proposal:
# before an object literal seals the object
# before a propoerty makes that property nonconfigurable and nonwritable.
All method properties are nonenumerable.
All value
On Sep 29, 2011, at 12:14 PM, Sean Eagan wrote:
On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
...
I haven't written the spec. for spread in argument lists but clearly
interior holes need to be passed as undefined. Trailing holes in a spread
in the
On Sep 29, 2011, at 9:03 PM, Sean Eagan wrote:
On Mon, Sep 26, 2011 at 7:27 PM, Waldemar Horwat walde...@google.com wrote:
Reached consensus on the following # proposal:
# before an object literal seals the object
# before a propoerty makes that property nonconfigurable and nonwritable.
All
On Thu, Sep 29, 2011 at 11:46 AM, Brendan Eich bren...@mozilla.com wrote:
BTW, we do properly parse JSON that defines a key named __proto__, and
IIRC V8 does not. I suspect (haven't checked) that V8 and other engines that
say __proto__ is not in and in particular not own for any object, but
On Thu, Sep 29, 2011 at 3:30 PM, Brendan Eich bren...@mozilla.com wrote:
The idea is that sealing an object is more common than freezing it, while
freezing a property is more common than sealing it.
I was thinking freezing an object is more common than sealing, but #
for freeze, ## for seal
On Sep 29, 2011, at 10:16 PM, Dean Landolt wrote:
because of no { on same line as the head, but it would not fix the second
case Waldemar showed:
if (a + b)/g f {f = (a + b)/g}
This case is a paren-full if head followed by an unbraced body, a useless
regexp expression statement. It's
On Sep 29, 2011, at 11:03 PM, Brendan Eich wrote:
Probably shouldn't have | for value types either then right ?
That's right, they are not objects.
Or hrm, now that you mention it Allen did spec these, and they get wrapped
implicitly (string foo becomes new String(foo), etc.).
I still find
On Sep 29, 2011, at 3:03 PM, Brendan Eich wrote:
On Sep 29, 2011, at 10:07 PM, Sean Eagan wrote:
...
So if #[] is added as shorthand for a sealed Array, do you agree that
#[0,,1] should be a syntax error ?
I thought I just said so (Sure, this carries over for all tuple proposals
in
On Thu, Sep 29, 2011 at 3:10 PM, Brendan Eich bren...@mozilla.com wrote:
I still find implicit primitive wrapping where the wrapper is observable
raises my hackles. Anyone feel the same?
I do. In ES5/strict code, nothing implicitly creates a *reachable* wrapper.
Put another way, if all your
On Sep 29, 2011, at 3:10 PM, Brendan Eich wrote:
On Sep 29, 2011, at 11:03 PM, Brendan Eich wrote:
Probably shouldn't have | for value types either then right ?
That's right, they are not objects.
Or hrm, now that you mention it Allen did spec these, and they get wrapped
implicitly
On Sep 29, 2011, at 11:34 PM, Allen Wirfs-Brock wrote:
I still find implicit primitive wrapping where the wrapper is observable
raises my hackles. Anyone feel the same?
Yes, but we have them and I don't seen anyway to eliminate them.
AFAIK, we have them is false in ES5 -- implicitly
On Sep 29, 2011, at 3:44 PM, Brendan Eich wrote:
AFAIK, we have them is false in ES5 -- implicitly created primitive
wrappers do not escape, and engines do optimize them away.
Yup, you are MarkM are correct about that. The implicit ones don't escape if
you keep inside strict mode.
On Thu, Sep 29, 2011 at 10:22, Brendan Eich bren...@mozilla.com wrote:
See dherman's minimal classes proposal, he minimized it slightly further on
the whiteboard, kind of after the meeting / with only a few people looking.
I still think minimal classes is smart if we're going to avoid too
On Sep 30, 2011, at 12:20 AM, Allen Wirfs-Brock wrote:
I don't see foo | abc as creating an implicit wrapping. I see it as
explicit wrapping as you have to create a wrapper in order to set
[[Prototype]] to foo.
Yes, it's not quite so bad in this light.
But, of limited utility.
On Sep 30, 2011, at 12:22 AM, Erik Arvidsson wrote:
4. Allow const classes
Hold this thought...
The question is do we have to solve these? I argue that we don't have
to solve these for ES.next. By postponing these we can provide an even
simpler class proposal that provides sugar to how
On Thu, Sep 29, 2011 at 4:22 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
However, it seems like all the issues we have seen are due to us
trying to solve issues that already exist today with prototype based
classes. These involve (but are not limited to):
1. Don't let uninitialized
On Thu, Sep 29, 2011 at 16:54, Brendan Eich bren...@mozilla.com wrote:
On Sep 30, 2011, at 12:22 AM, Erik Arvidsson wrote:
4. Allow const classes
Hold this thought...
The question is do we have to solve these? I argue that we don't have
to solve these for ES.next. By postponing these we
On Thu, Sep 29, 2011 at 17:08, Bob Nystrom rnyst...@google.com wrote:
class Monster {
constructor(this.name, this.health) {}
attack(target) {
log(Monster.attackMessage);
}
get isAlive() {
return this.health 0;
}
set health(value) {
if (value 0) throw new
On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
On Thu, Sep 29, 2011 at 17:08, Bob Nystrom rnyst...@google.com wrote:
class Monster {
constructor(this.name, this.health) {}
I 3 this. It beats the (public name, public health) variant in my view by
being explicit and not dragging in
On Sep 30, 2011, at 1:08 AM, Bob Nystrom wrote:
I like this. Maybe in pursuit of perfect we've lost sight of good?
Mainly we've over-constrained the design. The const instance variable problem
can be deferred. I claim we don't want any syntactic sugar for data properties
on the prototype.
On Sep 29, 2011, at 6:20 PM, Brendan Eich wrote:
On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
On Thu, Sep 29, 2011 at 17:08, Bob Nystrom rnyst...@google.com wrote:
class Monster {
constructor(this.name, this.health) {}
I 3 this. It beats the (public name, public health) variant
On Sep 30, 2011, at 2:25 AM, Oliver Hunt wrote:
On Sep 29, 2011, at 6:20 PM, Brendan Eich wrote:
On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
On Thu, Sep 29, 2011 at 17:08, Bob Nystrom rnyst...@google.com wrote:
class Monster {
constructor(this.name, this.health) {}
I 3 this.
On 09/29/2011 05:08 PM, Bob Nystrom wrote:
On Thu, Sep 29, 2011 at 4:22 PM, Erik Arvidsson erik.arvids...@gmail.com
mailto:erik.arvids...@gmail.com wrote:
However, it seems like all the issues we have seen are due to us
trying to solve issues that already exist today with prototype
On Sep 29, 2011, at 5:10 PM, Erik Arvidsson wrote:
On Thu, Sep 29, 2011 at 16:54, Brendan Eich bren...@mozilla.com wrote:
On Sep 30, 2011, at 12:22 AM, Erik Arvidsson wrote:
...
A static keyword is at this point traditional, but we all hate it.
Are we being too pure?
/be
I would also be
On Thu, Sep 29, 2011 at 18:38, Waldemar Horwat walde...@google.com wrote:
Yes, it's easier, but you'd also lose any convenient way of doing 5. 2, 4,
and 5 are the most important new features, and there isn't enough value in
classes to add them without those. If you find it difficult to come
52 matches
Mail list logo
