On Tue, Oct 2, 2012 at 9:05 PM, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
TC 39, I need decisions so that I can finish the Internationalization spec
and send it to the Ecma GA:
1) Instances of Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat
currently have
On Tue, Oct 2, 2012 at 10:13 AM, Brendan Eich bren...@mozilla.com wrote:
Allen Wirfs-Brock wrote:
On Oct 1, 2012, at 9:56 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We can try to tell ES implementors that they must do certain things in
order to be in conformance but that really
Mark S. Miller wrote:
Allen and I also discussed the plan I intend to try in
SpiderMonkey: making Date.prototype, Number.prototype, etc. test
as Object according to the O_p_toString_call tag test. We think
this should not affect SES or any real code (as Oliver postulated).
I
2012/10/2 Mark S. Miller erig...@google.com
On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich bren...@mozilla.com wrote:
Words on paper still carry force but they do not necessarily have prompt
effects, or any effects. It depends on the people reading them and
implementing, and trying to follow
On Oct 1, 2012, at 9:56 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We can try to tell ES implementors that they must do certain things in order
to be in conformance but that really doesn't work for code written by users
of the language.
You're right, we'd be letting usercode, not
On Oct 1, 2012, at 4:08 PM, Domenic Denicola wrote:
On Oct 1, 2012, at 18:58, Brendan Eich bren...@mozilla.org wrote:
I am warming up to the way CoffeeScript does things -- not the translation
scheme, __extends, __super__ -- rather, the plain Object instance created as
C.prototype that
On Mon, Oct 1, 2012 at 9:56 PM, Brendan Eich bren...@mozilla.com wrote:
But if we have a solid branding mechanism (like Domado's ideal in latest
browsers? ;-) then that should be used universally and this becomes a
don't-care.
MarkM suggested I should expound on what Domado does.
Domado
On Oct 1, 2012, at 10:37 PM, Brendan Eich wrote:
Brendan Eich wrote:
But if we have a solid branding mechanism (like Domado's ideal in latest
browsers? ;-) then that should be used universally and this becomes a
don't-care.
Just to be crystal clear:
* in pre-ES6 browsers, no
Allen Wirfs-Brock wrote:
On Oct 1, 2012, at 9:56 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
We can try to tell ES implementors that they must do certain things in order to
be in conformance but that really doesn't work for code written by users of the
language.
You're right, we'd be
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
Foo.isFoo = function (obj) {return !!obj.@FooBrand};
Using this strategy, will isFoo not fail, if the specified object came from
a
Having isFoo succeed on an instance of Bar is correct. But there's another
case that's more worrisome:
Foo foo = new Foo();
Baz baz = Object.create(foo);
By Allen's pattern, isFoo will also succeed on an instance of baz. OTOH,
were the branding done with a WeakMap or the brandcheck done with an
Allen Wirfs-Brock wrote:
I think we have all the language features need to do reliable
branding by ES programmers where they need it. We just need to
establish the patterns for doing that. Here is the one I propose:
private @FooBrand;
class Foo {
constructor() {
/* establish the
On Oct 2, 2012, at 10:18 AM, Kevin Smith wrote:
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
Foo.isFoo = function (obj) {return !!obj.@FooBrand};
Using this strategy, will isFoo
On Oct 2, 2012, at 10:47 AM, Mark S. Miller wrote:
Having isFoo succeed on an instance of Bar is correct. But there's another
case that's more worrisome:
Foo foo = new Foo();
Baz baz = Object.create(foo);
By Allen's pattern, isFoo will also succeed on an instance of baz. OTOH, were
On Oct 2, 2012, at 10:52 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
If you really need to strongly tie instantiation with branding you
probably have to use a factory function:
module Fooishness {
export function FooFactory ( ){return new Foo};
FooFactory.isFoo =
Allen Wirfs-Brock wrote:
On Oct 2, 2012, at 10:52 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
If you really need to strongly tie instantiation with branding you
probably have to use a factory function:
module Fooishness {
export function FooFactory ( ){return new Foo};
Herby Vojčík wrote:
It can be `arguments.isConstruct`, for example.
(One-handed Luke Skywalker voice:) NOo
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On the other hand, if you have many instances that need to be branded I
suspect that the distributed symbol based technique is going to have a
better performance profile than the WeakMaps.
Is this true? Are there performance caveats that come with current
WeakMap implementations?
Kevin
Brendan Eich wrote:
Herby Vojčík wrote:
It can be `arguments.isConstruct`, for example.
(One-handed Luke Skywalker voice:) NOo
Or whatever else, I just happened to write first thing where it could
reside.
/be
___
es-discuss
(One-handed Luke Skywalker voice:) NOo
: ) Another perfect response!
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Oct 2, 2012 at 11:01 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Oct 2, 2012, at 10:18 AM, Kevin Smith wrote:
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
Foo.isFoo
On Oct 2, 2012, at 2:46 PM, Mark S. Miller wrote:
On Tue, Oct 2, 2012 at 11:01 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 2, 2012, at 10:18 AM, Kevin Smith wrote:
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the
TC 39, I need decisions so that I can finish the Internationalization spec and
send it to the Ecma GA:
1) Instances of Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat
currently have [[Class]] Object. Should this change to Collator,
NumberFormat, and DateTimeFormat, respectively?
2)
At this point I'd go with Object (IOW, _stet_), unless Allen has a
thought.
/be
Norbert Lindenberg wrote:
TC 39, I need decisions so that I can finish the Internationalization spec and send it to the Ecma GA:
1) Instances of Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat
On Oct 2, 2012, at 9:46 PM, Brendan Eich wrote:
At this point I'd go with Object (IOW, _stet_), unless Allen has a thought.
I agree.
Regarding 3, if it is easy spec-wide to make the prototype non-instances that
would be preferable, but as long as the per instance state in the prototype is
On 30 September 2012 02:17, Brendan Eich bren...@mozilla.org wrote:
Failing to consult with implementors will just make editing churn. I don't
remember much discussion on this change, if any -- we did talk about the
general problem of prototype objects being firstborns of their class, and
how
I think Allen is absolutely right that the magic incest of current
built-ins is not going to scale, is semantically questionable, and
should best be abandoned.
: ) magic incest. This is pretty much a perfect response.
Kevin
___
es-discuss mailing
V8 says no to both. And I fail to see what benefit there is to
separating the two. In fact, it seems hostile to programmers to do so.
I think Allen is absolutely right that the magic incest of current
built-ins is not going to scale, is semantically questionable, and
should best be
On Sun, Sep 30, 2012 at 1:14 AM, Brendan Eich bren...@mozilla.org wrote:
V8 and SpiderMonkey agree. This avoids making two paths for built-in
constructor.prototype creation, one that makes a degenerate firstborn of the
class at hand, the other than makes an Object-instance prototype.
V8
Andreas Rossberg wrote:
Er, from my reading that's clearly not what the Wiki says for WeakMap.
And it also is not what V8 implements, for either WeakMap or Map.
Sorry, I was relying on Rick's testimony that the answers were 1) yes,
2) no.
V8 says no to both. And I fail to see what benefit
Nah, cheap shot. Let's reason together, not join taboo words.
The built-ins do what they do and it could be considered a botch to
abandon, but then there's still a scar lying between old and new
built-ins. And classes have to do one or both (we may want to self-host
built-ins with classes).
Oliver Hunt wrote:
FooPrototype being an instance of Foo makes things more complicated for no
obvious reason, and is only really used by conformance suites anyway :D
That's true enough.
The dubious backward compatibility claims are what they are, though, and
try inducting a bit: class C
Allen Wirfs-Brock wrote:
Line 5.c.v is dealing with the ES5 requirement that host objects not
reuse the listed [[Class]] values for anything other than the
specified built-ins. This version of toStrimg extends the spirit to
that restriction to all user or implementation defined tag values. It
On Mon, Oct 1, 2012 at 3:21 PM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
Er, from my reading that's clearly not what the Wiki says for WeakMap.
And it also is not what V8 implements, for either WeakMap or Map.
Sorry, I was relying on Rick's testimony that the answers
On Mon, Oct 1, 2012 at 3:30 PM, Brendan Eich bren...@mozilla.com wrote:
Erik Arvidsson wrote:
I'm with Allen, Andreas and others that the craziness needs to stop.
Which craziness?
That the prototype of the constructor needs to be a special case of
the instances created by the constructor.
Rick Waldron wrote:
On Mon, Oct 1, 2012 at 3:21 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Andreas Rossberg wrote:
Er, from my reading that's clearly not what the Wiki says for
WeakMap. And it also is not what V8 implements, for either
Erik Arvidsson wrote:
On Mon, Oct 1, 2012 at 3:30 PM, Brendan Eichbren...@mozilla.com wrote:
Erik Arvidsson wrote:
I'm with Allen, Andreas and others that the craziness needs to stop.
Which craziness?
That the prototype of the constructor needs to be a special case of
the instances created
On Mon, Oct 1, 2012 at 4:04 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
On Mon, Oct 1, 2012 at 3:21 PM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
Andreas Rossberg wrote:
Er, from my reading that's clearly not what the Wiki says for
On Oct 1, 2012, at 12:21 PM, Brendan Eich wrote:
...
The best reason for using Object is the one Mark raised: class (as sugar for
constructor/prototype) uses Object.
But if you've read the thread this far, my objective is not to enforce one
implementation approach or the other. It's to
On Oct 1, 2012, at 12:39 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Line 5.c.v is dealing with the ES5 requirement that host objects not reuse
the listed [[Class]] values for anything other than the specified built-ins.
This version of toStrimg extends the spirit to that restriction
It might be useful to list all the observable features to which valid instance
of might lead for a built-in BuiltIn.prototype, and check whether we want them
for new built-ins:
1) Object.prototype.toString.call(BuiltIn.prototype) returns [object BuiltIn].
True for ES5 objects, currently not
On Oct 1, 2012, at 2:44 PM, Norbert Lindenberg wrote:
It might be useful to list all the observable features to which valid
instance of might lead for a built-in BuiltIn.prototype, and check whether
we want them for new built-ins:
1) Object.prototype.toString.call(BuiltIn.prototype)
Allen Wirfs-Brock wrote:
On Oct 1, 2012, at 12:21 PM, Brendan Eich wrote:
...
The best reason for using Object is the one Mark raised: class (as sugar for
constructor/prototype) uses Object.
But if you've read the thread this far, my objective is not to enforce one
implementation approach or
Allen Wirfs-Brock wrote:
On Oct 1, 2012, at 12:39 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Line 5.c.v is dealing with the ES5 requirement that host objects not reuse the listed [[Class]]
values for anything other than the specified built-ins. This version of toStrimg extends the
Norbert Lindenberg wrote:
It might be useful to list all the observable features to which valid instance
of might lead for a built-in BuiltIn.prototype, and check whether we want them for
new built-ins:
1) Object.prototype.toString.call(BuiltIn.prototype) returns [object BuiltIn].
True for
Allen Wirfs-Brock wrote:
Any observable features I missed?
The relationship between the constructor and the prototype. EG:
Builtin.prototype.constructor === Builtin
Right! I forgot this a minute ago after showing how CoffeeScript does
it. D'oh.
I am warming up to the way CoffeeScript
On Oct 1, 2012, at 18:58, Brendan Eich bren...@mozilla.org wrote:
I am warming up to the way CoffeeScript does things -- not the translation
scheme, __extends, __super__ -- rather, the plain Object instance created as
C.prototype that has B.prototype as its [[Prototype]] but has shadowing
Domenic Denicola wrote:
On Oct 1, 2012, at 18:58, Brendan Eichbren...@mozilla.org wrote:
I am warming up to the way CoffeeScript does things -- not the translation
scheme, __extends, __super__ -- rather, the plain Object instance created as
C.prototype that has B.prototype as its
Brendan Eich wrote:
Erik Arvidsson wrote:
On Mon, Oct 1, 2012 at 3:30 PM, Brendan Eichbren...@mozilla.com
wrote:
Erik Arvidsson wrote:
I'm with Allen, Andreas and others that the craziness needs to stop.
Which craziness?
That the prototype of the constructor needs to be a special case of
On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
2) BuiltIn.prototype has state that lets BuiltIn methods successfully
operate on the object, at least as long as they don't modify the state.
True for ES5 objects, currently also true for ES Internationalization
objects. This means
Norbert Lindenberg wrote:
On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
2) BuiltIn.prototype has state that lets BuiltIn methods successfully operate
on the object, at least as long as they don't modify the state.
True for ES5 objects, currently also true for ES Internationalization
On Oct 1, 2012, at 3:48 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Let me try explaining this again,
No need to rehash.
Responding to my point about other legacy tag tests that are not twiddled
with ~ and so are possibly invalidated would be helpful. *Why* are the
core
Allen Wirfs-Brock wrote:
On Oct 1, 2012, at 3:48 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Let me try explaining this again,
No need to rehash.
Responding to my point about other legacy tag tests that are not
twiddled with ~ and so are possibly invalidated would be helpful.
On Oct 1, 2012, at 16:41 , Brendan Eich wrote:
Norbert Lindenberg wrote:
On Oct 1, 2012, at 15:53 , Brendan Eich wrote:
2) BuiltIn.prototype has state that lets BuiltIn methods successfully
operate on the object, at least as long as they don't modify the state.
True for ES5 objects,
Norbert Lindenberg wrote:
3) The state mentioned in 2) is modifiable.
True for some ES5 objects (Array, Date, RegExp),
Don't forget Object:-P.
I'm thinking of state that goes beyond an empty object and makes a BuiltIn instance function as a BuiltIn instance. Object instances have
Hi. Not filtering, just too busy to do more than skim.
On Mon, Oct 1, 2012 at 5:40 PM, Brendan Eich bren...@mozilla.org wrote:
Norbert Lindenberg wrote:
3) The state mentioned in 2) is modifiable.
True for some ES5 objects (Array, Date, RegExp),
Don't forget Object:-P.
I'm
Mark S. Miller wrote:
Regarding the integrity of original Object.prototype.toString.call as
a branding mechanism, I agree we need a new more general branding
mechanism. WeakMaps and Symbols both give us a place to hang this, but
we need a concrete proposal. The proposal should work both with
On Mon, Oct 1, 2012 at 8:17 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
Regarding the integrity of original Object.prototype.toString.call as a
branding mechanism, I agree we need a new more general branding mechanism.
WeakMaps and Symbols both give us a place to hang
Mark S. Miller wrote:
On Mon, Oct 1, 2012 at 8:17 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark S. Miller wrote:
Regarding the integrity of original
Object.prototype.toString.call as a branding mechanism, I
agree we need a new more
On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
[...]
Relaxing this requirement would still technically be a breaking change
from ES5 so we need to be cautious. But I bet we can get away with it if we
do it by ES6. By ES7 it will probably be
On Oct 1, 2012, at 9:02 PM, Brendan Eich wrote:
Mark S. Miller wrote:
On Mon, Oct 1, 2012 at 8:17 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark S. Miller wrote:
Regarding the integrity of original
Object.prototype.toString.call as a
Mark S. Miller wrote:
On Mon, Oct 1, 2012 at 9:02 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark S. Miller wrote:
[...]
Relaxing this requirement would still technically be a
breaking change from ES5 so we need to be cautious. But I bet
Allen Wirfs-Brock wrote:
We can try to tell ES implementors that they must do certain things in order to
be in conformance but that really doesn't work for code written by users of the
language.
You're right, we'd be letting usercode, not just some (benign or malign,
but if malign then game
Brendan Eich wrote:
But if we have a solid branding mechanism (like Domado's ideal in
latest browsers? ;-) then that should be used universally and this
becomes a don't-care.
Just to be crystal clear:
* in pre-ES6 browsers, no @@toStringTag in the language to hack around with.
* in ES6+
Norbert Lindenberg wrote:
Last week TC 39 approved a standard defining three new built-in constructors whose
instances and prototype objects all have [[Class]] Object. Also, the
prototype objects are not constructed by their respective constructors, but initialized
by them, e.g., as
Mark S. Miller wrote:
On Sat, Sep 29, 2012 at 10:21 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
I agree that the only security issue is avoiding the
communications channel.
Security aside, given maximin
class Foo
what do you suggest
I hadn't reviewed the 9-27 draft's 15.2.4.2 Object.prototype.toString ()
yet. It seems to suppress exceptions, which is bad (step 6(c)(ii)). The
...(iv) substitution of ??? for must be a placeholder but why not
throw there (in the case where @@toStringTag's value is not of String type)?
The
On Sunday, September 30, 2012 at 12:04 AM, Brendan Eich wrote:
Rick Waldron wrote:
On Sat, Sep 29, 2012 at 6:19 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
My intention, subject to feedback here and from TC39, is to
follow
Brendan Eich wrote:
The main thing I missed there is the prefixing of ~ on any tag
naming a core language built-in constructor. What's this for? Why not
for DOM built-ins too?
This step:
v. If tag is any of Arguments, Array, Boolean, Date, Error,
Function, JSON, Math, Number, Object,
Rick Waldron wrote:
Using the prototype object here:
Object.prototype.toString.call(Uint8Array.prototype).slice(8,-1))
But it's really usecase dependent, sorry for the noise
It's a who-cares for sure -- typed arrays are rolling, even in IE10
(could someone please test the above there).
On Sep 29, 2012, at 11:11 PM, Brendan Eich wrote:
Mark S. Miller wrote:
On Sat, Sep 29, 2012 at 10:21 PM, Mark S. Miller erig...@google.com
mailto:erig...@google.com wrote:
I agree that the only security issue is avoiding the
communications channel.
Security aside, given
On Sep 30, 2012, at 9:47 AM, Brendan Eich wrote:
Brendan Eich wrote:
The main thing I missed there is the prefixing of ~ on any tag naming a
core language built-in constructor. What's this for? Why not for DOM
built-ins too?
This step:
v. If tag is any of Arguments, Array, Boolean,
Thanks for your reply.
Why did I do this? Because, we are defining a significant number new
built-in classes and it is going to be increasingly hard to define
meaningful instance state for all such prototypes. It is also arguably
undesirable for most of these prototypes. Does any really
I think it is time to recognize that the built-in ES constructors have always
presented a class-like structure where it really is unnecessary and even
arguably undesirable for their associated prototype objects to also act as
instance objects. It's time to abandon that precedent and
On Sep 29, 2012, at 4:20 PM, Yusuke Suzuki wrote:
Thanks for your reply.
Why did I do this? Because, we are defining a significant number new
built-in classes and it is going to be increasingly hard to define
meaningful instance state for all such prototypes. It is also arguably
Allen Wirfs-Brock wrote:
However, there is a bigger issue here. You could have asked a similar
question about Map.prototype. Why isn't Map.prototype a Map instances? Is this
a bug or an intentional design decision?
Historically, the prototype objects associated with the 9 named built-in
Allen Wirfs-Brock wrote:
My intention, subject to feedback here and from TC39, is to follow
the pattern I used for Map as much as possible. However, TypedArray
object are all ready implemented by all major browsers to that may
limit how we apply it to them.
Implementations differ:
On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
However, there is a bigger issue here. You could have asked a similar
question about Map.prototype. Why isn't Map.prototype a Map instances? Is
this a bug or an intentional design decision?
On Sat, Sep 29, 2012 at 6:19 PM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
My intention, subject to feedback here and from TC39, is to follow the
pattern I used for Map as much as possible. However, TypedArray object are
all ready implemented by all major browsers to
Rick Waldron wrote:
On Sat, Sep 29, 2012 at 6:19 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
My intention, subject to feedback here and from TC39, is to
follow the pattern I used for Map as much as possible.
On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
However, there is a bigger issue here. You could have asked a similar
question about Map.prototype. Why isn't Map.prototype a Map instances? Is
this a bug or an intentional design decision?
On Sep 29, 2012, at 5:17 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
However, there is a bigger issue here. You could have asked a similar
question about Map.prototype. Why isn't Map.prototype a Map instances? Is
this a bug or an intentional design decision?
Historically, the
On Sep 29, 2012, at 7:23 PM, Rick Waldron wrote:
...
Subjectively, the examples here are exactly how I would expect (hope?) this
to behave, as the existing behaviour:
Array.prototype.push(1)
1
Array.prototype
[ 1 ]
...Has always been seemed strange ;)
I believe this is the
On Sep 29, 2012, at 7:26 PM, Rick Waldron wrote:
On Sat, Sep 29, 2012 at 6:19 PM, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
My intention, subject to feedback here and from TC39, is to follow the
pattern I used for Map as much as possible. However, TypedArray
Mark S. Miller wrote:
On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
However, there is a bigger issue here. You could have asked a
similar question about Map.prototype. Why isn't
On Sat, Sep 29, 2012 at 10:14 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
On Sat, Sep 29, 2012 at 5:17 PM, Brendan Eich bren...@mozilla.orgmailto:
bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
However, there is a bigger issue here. You could have
Allen Wirfs-Brock wrote:
As I covered in my reply to Brendan, I don't think these are
sufficiently defined to really answer. But if you definition of an
instance is that Object.prototype.toString.call(Map.prototype)
returns Map then the latest spec. draft does 1: yes, 2: no
That's precisely
Mark S. Miller wrote:
Security aside, given maximin
class Foo
what do you suggest Foo.prototype be?
If classes are sugar for constructor functions, an Object instance, just
as you'd get for
function Foo(){}
Foo.prototype
There has always been an unsightly difference between
Mark S. Miller wrote:
Security aside, given maximin
class Foo
what do you suggest Foo.prototype be?
I suggest adding @@toStringTag:Foo property to Foo.prototype when `class
Foo` is executed.
___
es-discuss mailing list
On Sat, Sep 29, 2012 at 10:21 PM, Mark S. Miller erig...@google.com wrote:
I agree that the only security issue is avoiding the communications
channel.
Security aside, given maximin
class Foo
what do you suggest Foo.prototype be?
That was too vague. Reformulating.
Private
Last week TC 39 approved a standard defining three new built-in constructors
whose instances and prototype objects all have [[Class]] Object. Also, the
prototype objects are not constructed by their respective constructors, but
initialized by them, e.g., as Intl.Collator.call({}).
Are you
91 matches
Mail list logo
