On Oct 17, 2014, at 12:52 AM, Claude Pache wrote:
>
> Le 17 oct. 2014 à 08:54, Isiah Meadows a écrit :
>
>> I was more looking for the rationale behind it. I know it currently
>> doesn't hoist.
>
> In the discussion pointed by Domenic, it is explained why classes don't hoist
> (namely, in or
nds` clause).
Is something not clear?
—Claude
>
> On Thu, Oct 16, 2014 at 8:55 PM, Domenic Denicola
> wrote:
>> https://www.google.com/search?q=class+declarations+hoisted+site%3Aesdiscuss.org
>> leads to
>> https://esdiscuss.org/topic/in-es6-strict-mode-do-function-d
I was more looking for the rationale behind it. I know it currently
doesn't hoist.
On Thu, Oct 16, 2014 at 8:55 PM, Domenic Denicola
wrote:
> https://www.google.com/search?q=class+declarations+hoisted+site%3Aesdiscuss.org
> leads to
> https://esdiscuss.org/topic/in-es6-strict-mo
https://www.google.com/search?q=class+declarations+hoisted+site%3Aesdiscuss.org
leads to
https://esdiscuss.org/topic/in-es6-strict-mode-do-function-declarations-within-a-block-hoist
as the first result which lays it out pretty clearly.
-Original Message-
From: es-discuss [mailto:es
I know it was touched on a recent thread
(https://esdiscuss.org/topic/a-new-es6-draft-rev28), but is there a
reason why class declarations aren't hoisted like function
declarations? It is a little confusing to be to type (1) but not (2).
(1)
```js
foo(); // prints "Yay!"
The first question maybe in all these discussions is what is needed or
not (in real life).
In BTF discussions I gave an example where (surprisingly) for an app
there were a very few prototype like declarations.
Because I just did not need it for this app.
The second question is maybe whether
On Fri, Mar 16, 2012 at 4:22 PM, Brendan Eich wrote:
>
> And properties can be used before initialization in JS today (and in Dart
> -- you Google guys are not all following the same rules :-P).
>
This is definitely the strangest possible venue for discussing Dart, but...
That isn't entirely tr
Sorry, I'd dropped too much context. Out of context, it looked like an
argument that could be applied both to instance variables and to lexical
variables. As applied only to instance variables, I'll hold off until I
have a coherent opinion ;)
On Fri, Mar 16, 2012 at 4:22 PM, Brendan Eich wrote:
On Fri, Mar 16, 2012 at 10:48 AM, Brendan Eich wrote:
>
> Not hermeneutic spirals, just circles. Feels like the last year (we cut
> off ES6 proposals, modulo exceptions/tweaks, last May; we had a big-ish
> classes strawman synthesized from several prior proposals; we lost Bob
> Nystrom to Dart).
Mark S. Miller wrote:
I agree with Waldemar. Classes aside, since code like
{
//...foo...
let x = 3;
function foo() { return x; }
//...
}
is statically legal, and is only wrong if foo is called before x is
initialized, the dynamic dead zone is very valuable. Otherwise, the
cal
I agree with Waldemar. Classes aside, since code like
{
//...foo...
let x = 3;
function foo() { return x; }
//...
}
is statically legal, and is only wrong if foo is called before x is
initialized, the dynamic dead zone is very valuable. Otherwise, the call to
foo() silently procee
Brendan Eich wrote:
We can defer these by deferring guards and const instance properties,
and tried to do so. But IIRC at least Waldemar was not happy leaving
writable instance properties usable (with default value undefined)
before being initialized.
Of course, Dart allows this and discloses
Axel Rauschmayer wrote:
We could certainly add a great many novelties to classes: use-before-definition
errors for instance variables, separate instance variables distinct from
properties, etc. etc.
protected as well as private names, another novelty.
TC39 prefers to avoid such innovation
> See https://gist.github.com/1329619 lines 59-73.
Take away the idea of `class` as an operator (honest question: is programmatic
construction of classes a use case that matters?) and it’s a very convincing
minimal proposal. Then you have the option of adding support for private name
objects an
Herby Vojčík wrote:
Brendan Eich wrote:
I noted to Jeremy that even his classes gist snuck in a novelty or two
(the one I remember is class evaluating and copying it
somehow). We need to avoid novelty, while accepting that doing so is to
some extent future-hostile because present-friendly.
C
Brendan Eich wrote:
I noted to Jeremy that even his classes gist snuck in a novelty or two
(the one I remember is class evaluating 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 please make
Axel Rauschmayer wrote:
I would be glad to see some gallery of minimal approaches, with easy
diffing showing the same code implemented in them (I would also
propose minimal classes of my own). But it is reasonable only when
minimal classes in general would be accepted as the way to go.
Exactl
> I would be glad to see some gallery of minimal approaches, with easy diffing
> showing the same code implemented in them (I would also propose minimal
> classes of my own). But it is reasonable only when minimal classes in general
> would be accepted as the way to go.
Exactly! Otherwise, we’l
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 t
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 the keyword `class`)? Unle
or and the prototype of an
object *are* related a little bit.
Naming ideas: delegate, meta-object (which a prototype is, in *some* ways)
> From: Allen Wirfs-Brock
> Subject: Re: array subclassing and class declarations
> Date: October 13, 2011 20:16:23 GMT+02:00
> To: Jay Skeer
> C
Le 14/10/2011 00:22, Allen Wirfs-Brock a écrit :
(...)
Proxy should be able to implement both Array and DOM object semantics (at least
I'm tried to push to make sure that proxies can implement full Array semantics).
I'm confident we're getting there :-)
However, the subclassing story (either
On Oct 13, 2011, at 1:32 PM, Erik Arvidsson wrote:
> On Wed, Oct 12, 2011 at 17:03, Allen Wirfs-Brock
> wrote:
>
>> Finally Alex said that he needs "extensible Array types" and said that "the
>> committee hasn't moved quickly on that" . A subsequent message clarified
>> that we was talking a
On Wed, Oct 12, 2011 at 17:03, Allen Wirfs-Brock wrote:
> Finally Alex said that he needs "extensible Array types" and said that "the
> committee hasn't moved quickly on that" . A subsequent message clarified that
> we was talking about "subclassing Array".
>
> I said that <| supports "array su
Le 13/10/2011 21:03, Jay Skeer a écrit :
> On 10/13/2011 11:37 AM, David Bruant wrote:
>> Le 13/10/2011 20:16, Allen Wirfs-Brock a écrit :
>>> On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
On 10/13/2011 09:23 AM, John J Barton wrote:
> For me this paragraph is a puzzle. A lot of the probl
On 10/13/2011 11:37 AM, David Bruant wrote:
Le 13/10/2011 20:16, Allen Wirfs-Brock a écrit :
On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
On 10/13/2011 09:23 AM, John J Barton wrote:
For me this paragraph is a puzzle. A lot of the problem for me is
"a property named prototype" vs [[Prototype
Le 13/10/2011 20:16, Allen Wirfs-Brock a écrit :
>
> On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
>
>> On 10/13/2011 09:23 AM, John J Barton wrote:
>>>
>>>
>>> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
>>> mailto:al...@wirfs-brock.com>> wrote:
>>>
>>> ..
>>>
>>>
>>>
>>> My unde
On Thu, Oct 13, 2011 at 11:16 AM, Allen Wirfs-Brock
wrote:
> This all arises from the language used in the ES specification. For the
> ES6 spec. I could, in theory, do a massive rename of [[Prototype]] to
> something else. However, I'm not sure whether such a renaming at this point
> in time wou
On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
> On 10/13/2011 09:23 AM, John J Barton wrote:
>>
>>
>>
>> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
>> wrote:
>> ..
>>
>> My understanding of <| is that it sets the [[prototype]] property and
>> nothing else. Consequently, I think t
On 10/13/2011 09:23 AM, John J Barton wrote:
On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
mailto:al...@wirfs-brock.com>> wrote:
..
My understanding of <| is that it sets the [[prototype]] property
and nothing else. Consequently, I think that the semantics of
"Array <|
On Oct 13, 2011, at 9:23 AM, John J Barton wrote:
>
>
> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
> wrote:
> ..
>
> My understanding of <| is that it sets the [[prototype]] property and nothing
> else. Consequently, I think that the semantics of "Array <| function(...){}"
> is to
On Oct 13, 2011, at 8:58 AM, David Bruant wrote:
> Le 13/10/2011 17:32, Allen Wirfs-Brock a écrit :
>>
>>
>>
>> you'd also need to include a constructor property in the new object in order
>> to make s instanceof SubArray work properly.
> Why so? "A instanceof B" only looks at B.prototype (dy
Here's a picture that may help:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aproto_operator&cache=cache&media=harmony:triangleupdate.pdf
On Oct 13, 2011, at 9:23 AM, John J Barton wrote:
>
>
> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
> wrote:
> ..
>
> My understand
oes is pretty magical
if you look at it from the perspective of machine language. But as language
designers, our job is to specify how the language works such that the apparent
magic is just sleight of hand. For us to have a language feature that we can
actually implement and standardize s
On Oct 13, 2011, at 12:23 PM, John J Barton wrote:
> If I get this right then:
>
> var Result = {prototype: aPrototype, foo: baz} <| function aTempFunction()
> { this.a = 'b';};
> var aResult = new Result();
>
> gives me {a:'b', __proto__:{__proto__:aPrototype} }
>
> Is it true? What h
On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock wrote:
> ..
>
> My understanding of <| is that it sets the [[prototype]] property and
> nothing else. Consequently, I think that the semantics of "Array <|
> function(...){}" is to create a function with the prototype chain as follow:
>
> (anon
On Oct 13, 2011, at 5:15 AM, David Bruant wrote:
> Le 13/10/2011 02:03, Allen Wirfs-Brock a écrit :
> ...
> So far so good
>
>> console.log(s instanceof Array); //true
> i think that this should be false.
> Object.getPrototypeOf(s) is the value of Object.getPrototypeOf(this) in the
> construct
Le 13/10/2011 17:32, Allen Wirfs-Brock a écrit :
On Oct 13, 2011, at 5:15 AM, David Bruant wrote:
Le 13/10/2011 02:03, Allen Wirfs-Brock a écrit :
...
So far so good
console.log(s instanceof Array); //true
i think that this should be false.
Object.getPrototypeOf(s) is the value of Object
Le 13/10/2011 02:03, Allen Wirfs-Brock a écrit :
(...)
If you want it to also inherit from Array prototype you can define proto such
as:
var proto = Array.prototype<| {/* additional "subclass" methods */};
Alex respond that new and instance of didn't work.
(using new to create DOM nodes is one
ors. Even if
this was allowed what would happen for
class Q extends P {...}
Is there anyway to subclass a proxy-based class and automatically get the
proxy based behavior in the subclass instances?
We pretty much concluded with Alex asserting that the class declarations
would provide a place to hang
if this
was allowed what would happen for
class Q extends P {...}
Is there anyway to subclass a proxy-based class and automatically get the proxy
based behavior in the subclass instances?
We pretty much concluded with Alex asserting that the class declarations would
provide a place to h
41 matches
Mail list logo
