Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 the rules. Those people are much more likely to audit their (closed, per release, typically) set of host objects and fix any spoofers. I think we're agreeing but for one thing. The force of a normative specification is that violations can be added to test262, so that they stand out like a sore thumb, putting pressure on the violator to fix it. We already did this successfully with one host object violation. But test262 can't really get out of its way and test host objects since they are implementation-dependent. I actually reported a couple of erroneous test cases that were relying on DOM features to work. We need WebIDL tests. For that matter, I'll try to attend testthewebforward in Paris at the end of the month [1] and start working on that if I do attend. I estimate the amount of work to get decent WebIDL (ECMAScript binding of browser APIs) coverage as ridiculously huge. David [1] http://testthewebforward.org/paris-2012.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes)
On 1 October 2012 21:17, Dean Landolt d...@deanlandolt.com wrote: Fair enough. But is there any value in a new typeof result? I surely can't see any. It's broken beyond repair -- I don't see the use in breaking more code trying to salvage it :P There isn't much value in a new typeof result as such. But it avoids the (potentially significant) _cost_ of requiring that every new primitive type ever introduced behaves like an object. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 just some (benign or malign, but if malign then game over already) host object, spoof a core language built-in. 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. /be Great, but this is really an orthogonal issue from my extensible Obj.proto.toString design. I did not intent that to be a branding mechanism. Using toString for branding of builtins is a crock that was enabled by the ES spec leaking one of its internal abstractions. toString's real role in life is just as a debugging aid that allows any object to present a string rendering of itself. My primary goal with Obj.proto.toString was to make that debugging aid more easily extensible as make it easier for developer to define new object abstractions (classes) that are reasonable identified in their Obj.proto.toString renderings. The only place that branding enters into this is in recognizing that existing working code uses Obj.proto.toString as a brand test for ES builtins. The ~ spoofing prevention is only there to ensure that such code isn't broken. A new branding mechanism may be a fine thing to have (more on that in another reply) and if we have one it should be universally applied. But that doesn't really have anything to do with toString as an extensible way to get a string object description or with the need to support legacy use of toString as a brand check on ES=5.1 builtins. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 has B.prototype as its [[Prototype]] but has shadowing
'constructor' set to C.
If I'm understanding correctly, this would be the same as
C.prototype = Object.create(B.prototype);
C.prototype.constructor = C;
which I thought was the recommended approach (although by who or where, I
admit I can't quite pinpoint). Am I on the right track? And can anyone else
comment on the commonality or recommendedness of this pattern, to see if
we're paving the right cow paths?
This is essentially how ES6 classes get wired up. Actually what they do is
closer to:
let tempProto = Object.create(B.prototype);
tempProto.constructor = function (constructor params) {constructor body);
tempProto.constructor.__proto__ = B;
tempProto.constructor.prototype = tempProto;
C=tempProto.constructor;
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
On 10/1/2012 6:43 PM, Brendan Eich wrote:
Nicholas C. Zakas wrote:
I've been playing around with the Set prototypes in Firefox and
Chrome (knowing full well that they are incomplete and the spec
hasn't been finalized yet), and I wanted to share a couple of learnings.
Thanks!
First, since a Set can be initialized with an array, it stands to
reason that you should be able to easily get an array back from the
set. However, there is no way to do that right now short of using a
loop and manually constructing an array. I would really like to see a
*Set.prototype.toArray* method to easily change the Set back into an
array. A simple use case would be de-duping an array:
function dedupe(array) {
return (new Set(array)).toArray();
}
Array.from is the way we hope to avoid burdening many iterables with
toArray methods, as Rick pointed out. Ok?
Better than okay, that's great. Having one way to convert iterables to
an array makes a lot of sense to me.
Second, the lack of visibility into Sets is problematic. A very
simple use case is when I want to see if the Set has been initialized
yet but I can't know what keys might have been used at that point in
time. Firefox implements a *Set.prototype.size* method which is
useful to know what I'm dealing with. However, I'm not sure how
frequently the number of items in the Set actually matters, so a
*Set.prototype.isEmpty* would be equally useful for this case.
+1 on isEmpty().
:D
Otherwise, I'm finding Sets very useful as a replacement for objects
that I was using for the same purpose.
Cool. Have you tried Maps for those cases where you want value -
value mappings?
Not yet, that's next on my list.
/be
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 uses an abstraction which I called 'Confidence', which I invented in
order to provide class-like behavior in terms of ES5; it is designed to
provide the security properties we needed with a minimum of implementation
mechanism, and is therefore not purely a branding abstraction. It uses one
WeakMap keyed by the instances (the objects confided in); the value is a
plain {} object which stores all of the “private fields” of the key-object.
There are four operations provided by a Confidence:
1. confide: add an instance to the WeakMap and create its private-state
record.
function TameNode() {
TameNodeConf.confide(this);
}
2. guard: test that an instance is in the WeakMap and return it or throw.
var TameNodeT = TameNodeConf.guard;
...
TameBackedNode.prototype.appendChild = nodeMethod(function (child) {
child = TameNodeT.coerce(child);
...
});
3. p: given an instance, return its private-state record.
var np = TameNodeConf.p.bind(TameNodeConf);
...
TameBackedNode.prototype.removeChild = nodeMethod(function(child) {
...
np(this).feral.removeChild(np(child).feral);
...
});
4. protectMethod: given a function, return a function with a guarded this.
var nodeMethod = TameNodeConf.protectMethod;
(usage examples above)
Note that unlike closure-based encapsulation, Confidence provides _sibling
amplification_; that is, a node method on one object can access the private
properties of another object, not only its own. This is not ideal as a
default for writing robust programs, but is useful to Domado since its
siblings interact (e.g. appendChild operates on two nodes from the same
DOM). An alternative abstraction which deemphasized sibling amplification
would be, for example, if protectMethod were defined such that the
wrapped function received an extra private-state argument and there was no
separate p operation (though sibling amplification can still be achieved
by having a protected method not exposed on the prototype).
The WeakMap used is the browser's WeakMap if available; otherwise we use an
emulation layer with inferior but sufficient garbage-collection properties
(implemented by SES or ES5/3; Domado is unaware of the distinction).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 @@toStringTag in the language to hack around with.
* in ES6+ browsers, the better branding mechanism and @toStringTag (one @) as
public symbol, no worries.
Yes, this makes a fork in JS code that wants to do tag testing. Old code must
use O_p_toString_call (original value of, safe call binding) and string
compare. New code wants the better and universal scheme.
/be
Yes, exactly what I envision. New code that needs to do branding should do it
in a new way. But I still think we need to protect the integrity of the old
mechanism in the presence of @@toStringTag.
It is also probably worthwhile taking a look at how internal branding is done
in the draft spec. for Map.
We also need to be careful about making a branding mechanism too prominent. If
we do, too many people will misuse it as a poor man's nominal type system when
they really should be doing behavior typing (or even more likely no explicit
type checking at all). Past experience is that excessive class brand checking
is an anti-pattern for dynamic OO languages.
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 internal Fooness of the instance */
this.@FooBrand = true;
}
}
Foo.isFoo = function (obj) {return !!obj.@FooBrand};
private @BarBrand;
class Bar extends Foo {
constructor() {
super();
/* establish the internal Barness of the instance */
this.@BarBrand = true;
}
}
Bar.isBar = function (obj) {return !!obj.@BarBrand};
Note that an instance of Bar will be true for both Foo.isFoo and Bar.isBar
This pattern is fine as long as it is ok that anything processed by the Foo or
Bar constructor gets branded because not, anybody can do:
let myFoo = Foo.call({ });
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 = function (obj) {return !!obj.@FooBrand};
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 letting usercode, not just some (benign or malign, but if malign then game over already) host object, spoof a core language built-in. 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. /be Great, but this is really an orthogonal issue from my extensible Obj.proto.toString design. I know, but I'm trying to simplify the spec further than you are. (Allen and I had a phone call -- thanks to that, better understanding of what's at stake.) Unfortunately, toString is used as a brand test by old code and SES (targeting pre-ES6 browsers). But rather than enshrine this forever, I would like to discuss breaking one case slightly in order to have a simpler spec. The case that the draft spec upholds is * New ES6+ browser, old and new script mixing, old script uses O_p_toString_call to tag-test and new script uses @toStringTag to spoof. I'd like to break this case, allowing old script in a new browser to be spoofed by new script using @toStringTag. Mark, is this a worry? If so then perhaps we are stuck with the complicated Object.prototype.toString in the latest draft. If not, and I would argue any SES subset must protect its old script from any spoofing new script, then we should try to unify [[NativeBrand]] and @@toStringTag by eliminating use of the former in Object.prototype.toString's spec, making the latter the sole extension mechanism. 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). Comments welcome, /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 different global context (frame)?
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 own
check
On Tue, Oct 2, 2012 at 10:12 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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 @@toStringTag in the language to hack around
with.
* in ES6+ browsers, the better branding mechanism and @toStringTag (one
@) as public symbol, no worries.
Yes, this makes a fork in JS code that wants to do tag testing. Old code
must use O_p_toString_call (original value of, safe call binding) and
string compare. New code wants the better and universal scheme.
/be
Yes, exactly what I envision. New code that needs to do branding should
do it in a new way. But I still think we need to protect the integrity of
the old mechanism in the presence of @@toStringTag.
It is also probably worthwhile taking a look at how internal branding is
done in the draft spec. for Map.
We also need to be careful about making a branding mechanism too
prominent. If we do, too many people will misuse it as a poor man's
nominal type system when they really should be doing behavior typing (or
even more likely no explicit type checking at all). Past experience is
that excessive class brand checking is an anti-pattern for dynamic OO
languages.
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 internal Fooness of the instance */
this.@FooBrand = true;
}
}
Foo.isFoo = function (obj) {return !!obj.@FooBrand};
private @BarBrand;
class Bar extends Foo {
constructor() {
super();
/* establish the internal Barness of the instance */
this.@BarBrand = true;
}
}
Bar.isBar = function (obj) {return !!obj.@BarBrand};
Note that an instance of Bar will be true for both Foo.isFoo and Bar.isBar
This pattern is fine as long as it is ok that anything processed by the
Foo or Bar constructor gets branded because not, anybody can do:
let myFoo = Foo.call({ });
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 = function (obj) {return !!obj.@FooBrand};
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
}
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 internal Fooness of the instance */
this.@FooBrand = true;
}
}
Foo.isFoo = function (obj) {return !!obj.@FooBrand};
private @BarBrand;
class Bar extends Foo {
constructor() {
super();
/* establish the internal Barness of the instance */
this.@BarBrand = true;
}
}
Bar.isBar = function (obj) {return !!obj.@BarBrand};
Note that an instance of Bar will be true for both Foo.isFoo and Bar.isBar
This pattern is fine as long as it is ok that anything processed by
the Foo or Bar constructor gets branded because not, anybody can do:
let myFoo = Foo.call({ });
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 = function (obj) {return !!obj.@FooBrand};
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
}
var iWillBeFoo = {};
Fooishness.FooFactory().constructor(iWillBeFoo);
In fact, it has its logic to `newFoo.@FooBrand = true;` in factory,
which solves it, hopefully cleanly enough.
Allen
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 not fail, if the specified object came from a
different global context (frame)?
Kevin
Indeed it would, but why shouldn't it? Foo in another frame is a different
class. If you need to do cross-frame brand, that seems like an additional
requirement would require additional mechanism.
Wouldn't a WeakMap branding scheme has similar issues. You would need to share
via some means a common WeakMap among constructors in different frames. Just
like to make symbol based branding work for this requirement you would have to
share a private symbol between frames.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 the branding done with a WeakMap or the brandcheck done with an own check Yes, you're correct an own property check is needed in isFoo. That is is one disadvantage of use private symbols as brands rather than WeakMaps. 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. My old GC writer self cringes at the possible perf impact many WeakMaps with large numbers of entries. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 = function (obj) {return !!obj.@FooBrand};
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
}
var iWillBeFoo = {};
Fooishness.FooFactory().constructor(iWillBeFoo);
In fact, it has its logic to `newFoo.@FooBrand = true;` in factory, which
solves it, hopefully cleanly enough.
Allen
Herby
Good catch, I forgot that the constructor is still exposed as a property on the
instance. The other way to prevent the constructor from being used to brand a
pre-existing object is force an instantiation inside the constructor:
private @FooBrand;
class Foo {
constructor() {
let newFoo = Object.create(Foo.prototype);
/* establish the internal Fooness of the instance */
newFoo.@FooBrand = true;
return newFoo;
}
}
Foo.isFoo = function (obj) {return Reflect.hasOwn(obj,@FooBrand)
!!obj.@FooBrand};
But this prevents Foo branding of subclasses of Foo. There is a tension here
that I don't think is necessarily resolvable. To me, it is another example why
such class branding should only be used in specific high integrity situations
and not as a general practice for all classes.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Test for [[Construct]] invocation (was: Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?))
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};
FooFactory.isFoo = function (obj) {return !!obj.@FooBrand};
private @FooBrand;
class Foo {
constructor() {
/* establish the internal Fooness of the instance */
this.@FooBrand = true;
}
}
}
var iWillBeFoo = {};
Fooishness.FooFactory().constructor(iWillBeFoo);
(here I missed `.call`)
In fact, it has its logic to `newFoo.@FooBrand = true;` in factory, which
solves it, hopefully cleanly enough.
Allen
Herby
Good catch, I forgot that the constructor is still exposed as a property on the
instance. The other way to prevent the constructor from being used to brand a
pre-existing object is force an instantiation inside the constructor:
private @FooBrand;
class Foo {
constructor() {
let newFoo = Object.create(Foo.prototype);
/* establish the internal Fooness of the instance */
newFoo.@FooBrand = true;
return newFoo;
}
}
Foo.isFoo = function (obj) {return Reflect.hasOwn(obj,@FooBrand)
!!obj.@FooBrand};
But this prevents Foo branding of subclasses of Foo. There is a
tension here that I don't think is necessarily resolvable. To me, it
is another example why such class branding should only be used in
specific high integrity situations and not as a general practice for
all classes.
Well, here (and in other cases, too) it would be handy to be able to
distinguish whether the call is constructor (new operator, super() call
in class constructor) or plain call (the rest). It can be
`arguments.isConstruct`, for example.
Than, it would simply be solved by `if (!arguments.isConstruct) return;`
(or throw) as the first line in constructor.
Allen
Herby
P.S.: Alternatively, this line can be intrinsic property of class
constructor, but this makes class special and not a desugaring any more...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Test for [[Construct]] invocation (was: Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?))
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
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Test for [[Construct]] invocation (was: Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?))
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 mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Test for [[Construct]] invocation (was: Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?))
(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
Re: Suggestions for Set
On Mon, Oct 1, 2012 at 11:46 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Brendan Eich
Sent: Monday, October 1, 2012 21:43
To: Nicholas C. Zakas
I would really like to see a *Set.prototype.toArray* method to easily
change the Set back into an array. A simple use case would be de-duping an
array:
function dedupe(array) {
return (new Set(array)).toArray();
}
Array.from is the way we hope to avoid burdening many iterables with
toArray methods, as Rick pointed out. Ok?
Also:
function dedupe(array) {
return [...new Set(array)];
}
I'm not sure we ended up with iteration for spread?
Another alternative:
function dedupe(array) {
return [x for x of new Set(array)];
}
This works in Firefox Aurora, for the record :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
On Tue, Oct 2, 2012 at 4:26 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
On Mon, Oct 1, 2012 at 11:46 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:
es-discuss-boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Monday, October 1, 2012 21:43
To: Nicholas C. Zakas
I would really like to see a *Set.prototype.toArray* method to easily
change the Set back into an array. A simple use case would be de-duping an
array:
function dedupe(array) {
return (new Set(array)).toArray();
}
Array.from is the way we hope to avoid burdening many iterables with
toArray methods, as Rick pointed out. Ok?
Also:
function dedupe(array) {
return [...new Set(array)];
}
I'm not sure we ended up with iteration for spread?
Another alternative:
function dedupe(array) {
return [x for x of new Set(array)];
}
No iteration for spread, per July 24 resolution
https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html
Rick
This works in Firefox Aurora, for the record :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Suggestions for Set
From: Rick Waldron [waldron.r...@gmail.com] Sent: Tuesday, October 02, 2012 16:52 No iteration for spread, per July 24 resolution https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html Oh, thanks for catching me on that. Silly Firefox... This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iterables? Does [...x] throw for an iterable, or result in something else? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
On Tue, Oct 2, 2012 at 5:11 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] Sent: Tuesday, October 02, 2012 16:52 No iteration for spread, per July 24 resolution https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html Oh, thanks for catching me on that. Silly Firefox... This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iterables? Does [...x] throw for an iterable, or result in something else? The direct reasoning for the resolution was: Cannot be both iterable and array-like It's possible that this could be added to the agenda for november, if Brendan wants to discuss SpiderMonkey's experience implementing it. It seems to me that if they're not having issues then it's at least worth a mention. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
On Tue, Oct 2, 2012 at 2:18 PM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Oct 2, 2012 at 5:11 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] Sent: Tuesday, October 02, 2012 16:52 No iteration for spread, per July 24 resolution https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html Oh, thanks for catching me on that. Silly Firefox... This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iterables? Does [...x] throw for an iterable, or result in something else? The direct reasoning for the resolution was: Cannot be both iterable and array-like It's possible that this could be added to the agenda for november, if Brendan wants to discuss SpiderMonkey's experience implementing it. It seems to me that if they're not having issues then it's at least worth a mention. Please do. I'd really like to see a more pleasant resolution if one can be found. What does SpiderMonkey actually do? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 = function (obj) {return !!obj.@FooBrand};
Using this strategy, will isFoo not fail, if the specified object came
from a different global context (frame)?
Kevin
Indeed it would, but why shouldn't it? Foo in another frame is a
different class. If you need to do cross-frame brand, that seems like an
additional requirement would require additional mechanism.
Wouldn't a WeakMap branding scheme has similar issues. You would need to
share via some means a common WeakMap among constructors in different
frames. Just like to make symbol based branding work for this requirement
you would have to share a private symbol between frames.
For classes, I agree it should fail cross frame -- they are different
classes. But what about builtins? Note that ES5 [[Class]] is a cross-frame
brand for builtins. And Array.isArray is an ad-hoc one-off cross-frame
brand check.
Allen
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Suggestions for Set
From: Rick Waldron [mailto:waldron.r...@gmail.com] Sent: Tuesday, October 2, 2012 17:18 On Tue, Oct 2, 2012 at 5:11 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Rick Waldron [waldron.r...@gmail.com] Sent: Tuesday, October 02, 2012 16:52 No iteration for spread, per July 24 resolution https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html Oh, thanks for catching me on that. Silly Firefox... This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iterables? Does [...x] throw for an iterable, or result in something else? The direct reasoning for the resolution was: Cannot be both iterable and array-like I can't really understand what this is trying to say. It must be because I don't understand iterable. Doesn't it just mean responds to for-of? I would imagine arrays, NodeLists, arguments, and other array-likes all respond to for-of; if they don't, that seriously decreases the utility of for-of! It's possible that this could be added to the agenda for november, if Brendan wants to discuss SpiderMonkey's experience implementing it. It seems to me that if they're not having issues then it's at least worth a mention. Yay! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
On Oct 2, 2012, at 2:43 PM, Mark S. Miller wrote: On Tue, Oct 2, 2012 at 2:18 PM, Rick Waldron waldron.r...@gmail.com wrote: The direct reasoning for the resolution was: Cannot be both iterable and array-like It's possible that this could be added to the agenda for november, if Brendan wants to discuss SpiderMonkey's experience implementing it. It seems to me that if they're not having issues then it's at least worth a mention. Please do. I'd really like to see a more pleasant resolution if one can be found. What does SpiderMonkey actually do? This thread from July is relevant https://mail.mozilla.org/pipermail/es-discuss/2012-July/023918.html In particular On Jul 5, 2012, at 10:54 AM, Brendan Eich wrote: Allen privately observed that Array forEach skips holes, matching for-in. That counts for a lot with me -- we have only a blind for(i=0;ia.length;i++)... loop not skipping holes, but of course it wouldn't. That is weak precedent on which to build for-of. Specifically, for consistency, I think array.forEach((v)=console.log(v)); and for (let v of array) console.log(v); should yield the same results. [].forEach skips holes so the default iterator for arrays should too. All the other Array extras also have the skipping behavior. Map may win at some point, who knows? It's not winning if one wants an array, numeric indexing, .length, the usual prototype methods. We could consider also have dense interators available: for (let v of array.denseValues) console.log(v); Allen Hopefully we don't have to re-discuss too much of this. allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 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 different global context (frame)?
Kevin
Indeed it would, but why shouldn't it? Foo in another frame is a different
class. If you need to do cross-frame brand, that seems like an additional
requirement would require additional mechanism.
Wouldn't a WeakMap branding scheme has similar issues. You would need to
share via some means a common WeakMap among constructors in different frames.
Just like to make symbol based branding work for this requirement you would
have to share a private symbol between frames.
For classes, I agree it should fail cross frame -- they are different
classes. But what about builtins? Note that ES5 [[Class]] is a cross-frame
brand for builtins. And Array.isArray is an ad-hoc one-off cross-frame brand
check.
If you take a look at the recent draft spec. for Map you will see that is uses
an internal branding check that is supposed to work across frame. If that
check is properly implemented then one can code
function isBuiltinMap(obj) {
try {
Map.prototype.size.call(obj)
} catch (e) {return false};
return true;
}
But this does raise an interesting question for self-host built-in and for any
user self hosted class definitions.
The spec leaves it up to the Map implementation to define the mechanism for
testing for the presence of [[MapData]]. But, in an ES self hosted
implementation a private symbol or WeakMap registry are probably the two most
plausible available mechanisms. Both of these would require some secure
mechanism for cross frame sharing in order make the branding work cross frame.
I don't think we currently have this. Perhaps it is a module loader issue. Or
perhaps it is an implementation issue. If built-ins have magic powers and the
implementation wants to support self hosting of built-in then perhaps it's the
implementation responsibility to provide the mechanism for granting those
powers.
Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
Domenic Denicola wrote: From: Rick Waldron [mailto:waldron.r...@gmail.com] This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iterables? Does [...x] throw for an iterable, or result in something else? The direct reasoning for the resolution was: Cannot be both iterable and array-like I can't really understand what this is trying to say. It must be because I don't understand iterable. Doesn't it just mean responds to for-of? It means (in ES6, SpiderMonkey uses a string property name 'iterator') that the object in question (is obj iterable?) has an @iterator property, which when called gets or creates an iterator for obj. I would imagine arrays, NodeLists, arguments, and other array-likes all respond to for-of; if they don't, that seriously decreases the utility of for-of! Array.from is that an object is either iterable, or failing that, array-like (even if no .length property, ToUint32(undefined) = 0 so no elements). See bottom of https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html. As Allen's followup points out, array iteration skips holes, to match Array.prototype.forEach. Should spread fill holes or skip them? It's possible that this could be added to the agenda for november, if Brendan wants to discuss SpiderMonkey's experience implementing it. It seems to me that if they're not having issues then it's at least worth a mention. Yay! I actually do not remember why we went back to only array-like instead of iterable || array-like for spread. Can someone (Rick? Dave? Arv?) recall? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
Brendan Eich wrote: I would imagine arrays, NodeLists, arguments, and other array-likes all respond to for-of; if they don't, that seriously decreases the utility of for-of! Array.from is s/is/tests/ that an object is either iterable, or failing that, array-like (even if no .length property, ToUint32(undefined) = 0 so no elements). See bottom of https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html. As for the list of built-ins after arrays, specifically NodeLists, arguments, ... I agree these should all be iterable. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
On Oct 2, 2012, at 3:55 PM, Brendan Eich wrote: Domenic Denicola wrote: From: Rick Waldron [mailto:waldron.r...@gmail.com] This seems like an unfortunate decision, and I couldn't discern the motivation in the minutes. When would I want to use a syntax that fails for iterables? Does [...x] throw for an iterable, or result in something else? The direct reasoning for the resolution was: Cannot be both iterable and array-like I can't really understand what this is trying to say. It must be because I don't understand iterable. Doesn't it just mean responds to for-of? It means (in ES6, SpiderMonkey uses a string property name 'iterator') that the object in question (is obj iterable?) has an @iterator property, which when called gets or creates an iterator for obj. I would imagine arrays, NodeLists, arguments, and other array-likes all respond to for-of; if they don't, that seriously decreases the utility of for-of! Array.from is that an object is either iterable, or failing that, array-like (even if no .length property, ToUint32(undefined) = 0 so no elements). See bottom of https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html. But also see https://bugs.ecmascript.org/show_bug.cgi?id=588 and in particular comment 1 which says: Did we talk about the implications of of using iterable protocol if the array has holes? The proposed standard iterator for Arrays turns holes into undefined. While normal array-like iteration skips holes. I would expect that let a2 = Array.from([5]); would produce a new array that was just like the argument array. But using iterator protocol would make it just like: let a3 = Array.from([undefined, undefined, undefined, undefined, 5]); It seems to me that the right solution, is that if the from argument is a real Array then Array-like, hole preservation, iteration should be used. If it isn't a real Array, then from should first try iterable protocol and if it isn't there fall back to array-like. As Allen's followup points out, array iteration skips holes, to match Array.prototype.forEach. Should spread fill holes or skip them? Holes need to be skipped if we expect var arrayWithHoles = [,,2,,,5]; var copyOfArrayWithHoles = [...arrayWithHoles]]; to make an accurate copy. It's possible that this could be added to the agenda for november, if Brendan wants to discuss SpiderMonkey's experience implementing it. It seems to me that if they're not having issues then it's at least worth a mention. Yay! I actually do not remember why we went back to only array-like instead of iterable || array-like for spread. Can someone (Rick? Dave? Arv?) recall? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ecma 402 (i18n API) v2.0 features list
This list is good input for the meeting. As a reminder of smaller items that didn't make it into edition 1.0, plus some possible enhancements, I also filed some tickets: https://bugs.ecmascript.org/buglist.cgi?product=ECMAScript%20Internationalization%20APIcomponent=Specification%20Draftresolution=--- Another feature that's been mentioned are relative dates, e.g., a moment ago, 3 hours ago, 5 months ago, in 3 days. Note that as an Ecma group we have to keep records in standard archives, i.e., wiki.ecmascript.org for feature proposals, bugs.ecmascript.org for smaller items, and members.ecma-international.org for minutes. Norbert On Sep 27, 2012, at 9:14 , Nebojša Ćirić wrote: https://docs.google.com/spreadsheet/ccc?key=0AhsGcaqNtRMpdC1FVEZOZ2tqdWRHdWdtRkMyaFM3VGc#gid=0 Please take a look at the document. Add new or comment on existing features. I'll send a calendar invite shortly. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ecma 402 (i18n API) v2.0 features list
We'll send meeting notes to Patrick, and any drafts/strawman will be posted to wiki. 2012/10/2 Norbert Lindenberg ecmascr...@norbertlindenberg.com This list is good input for the meeting. As a reminder of smaller items that didn't make it into edition 1.0, plus some possible enhancements, I also filed some tickets: https://bugs.ecmascript.org/buglist.cgi?product=ECMAScript%20Internationalization%20APIcomponent=Specification%20Draftresolution=--- Another feature that's been mentioned are relative dates, e.g., a moment ago, 3 hours ago, 5 months ago, in 3 days. Note that as an Ecma group we have to keep records in standard archives, i.e., wiki.ecmascript.org for feature proposals, bugs.ecmascript.org for smaller items, and members.ecma-international.org for minutes. Norbert On Sep 27, 2012, at 9:14 , Nebojša Ćirić wrote: https://docs.google.com/spreadsheet/ccc?key=0AhsGcaqNtRMpdC1FVEZOZ2tqdWRHdWdtRkMyaFM3VGc#gid=0 Please take a look at the document. Add new or comment on existing features. I'll send a calendar invite shortly. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestions for Set
Allen Wirfs-Brock wrote: Did we talk about the implications of of using iterable protocol if the array has holes? We did, and some of us agreed that a.forEach skips holes, so for (v of a) should too. But you are right, that means spread can't sensibly use iteration. On the other hand, drafted and prototyped iteration on arrays does not currently skip holes. It fills them in argument list and enclosing array literals. In the latter it could preserve holes rather than filling them with undefined values, but in argument lists there's no such thing as a hole. Which is more important, iterating over holes (preserved if possible), or skipping them and therefore spreading array-likes but not iterables? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Test for [[Construct]] invocation (was: Re: Must built-inprototypes also be valid instances? (Was: Why DataView.prototypeobject's [[Class]] is Object?))
You ask jS how I do ask a class function: if (config is instanceof V.Construction) return; - please read how I'm doing such a class function: http://metadea.de/V/default.aspx#V_construct_and_your_class It's really the only function syntax to do real OOP, in javaScript. I'd like to fork Function function but the main functionality is to check if it prototypes (prototyping), if it returns itself, undefined or throws an exception (functioning) or the function constructs the object instance (constructing). Read! /Uli From: Kevin Smith Sent: Tuesday, October 02, 2012 10:11 PM To: Brendan Eich Cc: es-discuss Subject: Re: Test for [[Construct]] invocation (was: Re: Must built-inprototypes also be valid instances? (Was: Why DataView.prototypeobject's [[Class]] is Object?)) (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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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) If the answer to 1) is yes: The prototype objects of Intl.Collator,
Intl.NumberFormat, and Intl.DateTimeFormat currently have [[Class]] Object.
Should this change to Collator, NumberFormat, and DateTimeFormat,
respectively?
3) If the answer to 1) or 2) is no: The prototype objects of Intl.Collator,
Intl.NumberFormat, and Intl.DateTimeFormat currently have all the state that
allows them to be used as instances. Should they not have that state, and
instead be plain objects with methods?
If I don't get votes from at least 10 of the usual TC 39 attendees within the
next 24 hours, and a clear majority for change, the spec will remain as
approved at the meeting two weeks ago.
Thanks,
Norbert
On Sep 29, 2012, at 23:08 , Brendan Eich wrote:
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 Intl.Collator.call({}).
Are you suggesting they should have Collator, NumberFormat, and
DateTimeFormat, respectively, and the prototypes be specified as being
constructed by their constructors?
All else equal, yes (sorry for not flagging these).
Any non-equal elses in sight?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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 currently have [[Class]] Object. Should this change to Collator, NumberFormat, and DateTimeFormat, respectively?
2) If the answer to 1) is yes: The prototype objects of Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat currently have [[Class]] Object. Should this change to Collator, NumberFormat, and DateTimeFormat, respectively?
3) If the answer to 1) or 2) is no: The prototype objects of Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat currently have all the state that allows them to be used as instances. Should they not have that state, and instead be plain objects with methods?
If I don't get votes from at least 10 of the usual TC 39 attendees within the next 24 hours, and a clear majority for change, the spec will remain as approved at the meeting two weeks ago.
Thanks,
Norbert
On Sep 29, 2012, at 23:08 , Brendan Eich wrote:
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 Intl.Collator.call({}).
Are you suggesting they should have Collator, NumberFormat, and DateTimeFormat, respectively, and the prototypes be specified as being constructed by their constructors?
All else equal, yes (sorry for not flagging these).
Any non-equal elses in sight?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is Object?)
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
immutable I think it would be ok leaving it as currently specified.
Allen
/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
currently have [[Class]] Object. Should this change to Collator,
NumberFormat, and DateTimeFormat, respectively?
2) If the answer to 1) is yes: The prototype objects of Intl.Collator,
Intl.NumberFormat, and Intl.DateTimeFormat currently have [[Class]]
Object. Should this change to Collator, NumberFormat, and
DateTimeFormat, respectively?
3) If the answer to 1) or 2) is no: The prototype objects of
Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat currently have all
the state that allows them to be used as instances. Should they not have
that state, and instead be plain objects with methods?
If I don't get votes from at least 10 of the usual TC 39 attendees within
the next 24 hours, and a clear majority for change, the spec will remain as
approved at the meeting two weeks ago.
Thanks,
Norbert
On Sep 29, 2012, at 23:08 , Brendan Eich wrote:
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
Intl.Collator.call({}).
Are you suggesting they should have Collator, NumberFormat, and
DateTimeFormat, respectively, and the prototypes be specified as being
constructed by their constructors?
All else equal, yes (sorry for not flagging these).
Any non-equal elses in sight?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
