On Jan 20, 2012, at 4:07 PM, David Bruant wrote:
* What are all the cases in nowadays browsers where a new
Object.prototype.__proto__ can be dynamically created? (The only one I
can think of is same-domain iframe, but I think there exists some weird
rules for one frame to access another by
On Wed, Jan 25, 2012 at 10:28 PM, Brendan Eich bren...@mozilla.org wrote:
The form you showed was every bit as imperative. I don't like punning 'if'
statements into object literals as a special form.Why not switch statements?
Why not loops with computed property names?
Switch statements could
Lasse Reichstein wrote:
The argument here seems to be that the need for conditionally
declaring properties of an object literal isn't happening often enough
that it warrants an abstraction. (And that seems reasonable from what
I've seen too).
The problem with this the process of discussion.
On Sat, Jan 28, 2012 at 1:10 AM, Brendan Eich bren...@mozilla.org wrote:
Tom Van Cutsem mailto:tomvc...@gmail.com
January 27, 2012 10:53 AM
Off-topic: What is the recommended style for naming modules?
Capitalized and camel-cased? It’s nothing I couldn’t get used to,
but it seems
Is the window.opera object in fact a host object? From the documentation at
http://www.howtocreate.co.uk/operaStuff/operaObject.html, it seems the
only magic behavior is in its methods, not in the object itself. Is there
something magical about the behavior of this object itself?
Note that just
On Jan 27, 2012, at 10:15 PM, John-David Dalton wrote:
I noticed in the ES6 draft it states that host objects *do not* have
the [[NativeBrand]] internal property.
I think do not have should be reworded to are not required to have.
This would allow existing inferences like
On Jan 28, 2012, at 8:21 AM, Allen Wirfs-Brock wrote:
On Jan 27, 2012, at 10:15 PM, John-David Dalton wrote:
I noticed in the ES6 draft it states that host objects *do not* have
the [[NativeBrand]] internal property.
I think do not have should be reworded to are not required to have.
I don't think we should change __proto__ unnecessarily from current
implementations, including making it an accessor. Neither JSC nor
SpiderMonkey does that.
We do need the ability to delete it, so it should live on
Object.prototype and be configurable.
Ignoring the don't gild the lily (or
The proposal for | cites these usage examples:
- Setting the prototype of a function to something other than
Function.prototype
let f = EnhancedFunctionPrototype | function () {}
- Parrallel constructor/instance prototype chains
let superclass = function () {};
//define a
Le 28/01/2012 18:16, Brendan Eich a écrit :
I don't think we should change __proto__ unnecessarily from current
implementations, including making it an accessor. Neither JSC nor
SpiderMonkey does that.
We do need the ability to delete it, so it should live on
Object.prototype and be
Le 28/01/2012 09:28, Herby Vojčík a écrit :
The proposal for | cites these usage examples:
- Setting the prototype of a function to something other than
Function.prototype
let f = EnhancedFunctionPrototype | function () {}
- Parrallel constructor/instance prototype chains
let
@MarkM
Is there something magical about the behavior of this object itself?
For kicks the magical bit would be its awesome pre ES6 internal
[[Class]] value.
Can we leave magical out of a spec convo?
Note that just because the object itself is non-standard and provided by the
host does not
@Allen
I probably need to be more explicit about host objects and add another step
just before step 5
If O is a host object, let tag be an implementation defined string value.
The value may not be Array, Boolean, Date, Error, Function,
JSON, Math, Number, Object, RegExp, and String.
+1
David Bruant wrote:
Le 28/01/2012 09:28, Herby Vojčík a écrit :
The proposal for| cites these usage examples:
- Setting the prototype of a function to something other than
Function.prototype
let f = EnhancedFunctionPrototype| function () {}
- Parrallel constructor/instance prototype
Hello,
in ES, inheritance between classes was in fact only inheritance
between their prototypes; the constructor functions always inherited
from Function.prototype directly.
Now, | operator defines that
Fun | function SubFun (...) { ... }
not only does parallel hierarchy so that
Herby Vojčík wrote:
Now, | operator defines that
Fun | function SubFun (...) { ... }
not only does parallel hierarchy so that
errata: delete not only
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The current ES6 draft defines its like this:
15.2.4.2 Object.prototype.toString ( )
When the toString method is called, the following steps are taken:
If the this value is undefined, return [object Undefined].
If the this value is null, return [object Null].
Let
Le 28/01/2012 18:16, Brendan Eich a écrit :
I don't think we should change __proto__ unnecessarily from current
implementations, including making it an accessor. Neither JSC nor
SpiderMonkey does that.
If the spec includes an optional normative definition of __proto__ that
requires it to be
Under the open issues for Quasi Literals,
http://wiki.ecmascript.org/doku.php?id=harmony:quasis#nesting , the
topic of nesting is brought up.
After implementing Quasi Literals in Traceur it is clear that
supporting nested quasi literals is easier than not supporting them.
What is the argument for
On Jan 28, 2012, at 11:33 AM, John-David Dalton wrote:
@Allen
Also, the definition of Host Object needs to be tighten up to make it clear
that an object is only a host object if it has some magical behavior.
-1 magical.
the spec. won't actually say magical, but the important
I don't think we would ever want to expose __proto__ as an accessor property on
Object.prototype as that would expose set/get functions that would also have
the capabilities of __proto__ without being associated with that special
property.
I can easily write a specification for __proto__
This is really relaxing the (over-restrictive, IMHO) design that says
that for ${expr} in a quasi, expr can be only a very few forms such as
Identifier, Identifier '.' IdentifierName, and the like -- right?
I.e. if we allow expr to be the grammar's Expression non-terminal, then
it follows
@Allen
We want to be able to define things that were historically implemented as
host objects using pure ECMAScript code. One things such objects have done
is to extend the range of values produced by Object.prototype.toString. So,
we need a pure ECMAScript way to accomplish that.
You
Axel Rauschmayer wrote:
Alternative:
$ Object.prototype.toString.call(true)
'[primitive boolean]'
No gratuitous runtime incompatibility, it will only break compat and
punish early browser impelmentations. We've been over this. Please
resist the urge to clean things up.
/be
On Sat, Jan 28, 2012 at 16:07, Brendan Eich bren...@mozilla.org wrote:
This is really relaxing the (over-restrictive, IMHO) design that says that
for ${expr} in a quasi, expr can be only a very few forms such as
Identifier, Identifier '.' IdentifierName, and the like -- right?
Yes. Only
On Jan 28, 2012, at 4:07 PM, John-David Dalton wrote:
@Allen
We want to be able to define things that were historically implemented as
host objects using pure ECMAScript code. One things such objects have done
is to extend the range of values produced by Object.prototype.toString. So,
@Allen
and name the internal property [[Class]]. But then, how would you
implement it in pure ES code?
You can name the internal property whatever you want [[Class]] /
[[NativeBrand]] / [[Whatevz]]. It's internal so less important to me
what the name is.
I don't think setting
John-David Dalton wrote:
Also note that [[Class]] doesn't actually exist as string valued per object
state in many implementations. That is one of the problems with the current spec, it
creates the impression that it such state actually exists.
Sounds like a per implementation issue/detail.
@/be
No, we do not want normative spec language requiring a per-object
private-named property that determines the
Object.prototype.toString.call(x).slice(8,-1) result.
Doing this naively will both impose unacceptable overhead *and* allow
type-confusion attacks.
I'm talking about adding
At least, if you consider |with| and |eval| fun (and who doesn't?):
js var x = outer; function f() { with({ x: 17 }) eval(var x); return x;
} typeof f()
undefined
This seems to be the behavior in every engine out there. But according to the last ES5
errata for 10.5, and in the latest ES6
[new subject line]
On Sat, Jan 28, 2012 at 12:03 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
[...]
Moreover, many host objects are implemented in JS itself -- e.g. some
standard libraries as in Node.js. I called them inefficiently as
native-host objects.
I'm not as familiar with
On Sat, Jan 28, 2012 at 2:27 PM, John-David Dalton
john.david.dal...@gmail.com wrote:
@MarkM
Is there something magical about the behavior of this object itself?
For kicks the magical bit would be its awesome pre ES6 internal
[[Class]] value.
Sigh. I just tested an you are correct.
On Sat, Jan 28, 2012 at 7:11 PM, Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
Alternative:
$ Object.prototype.toString.**call(true)
'[primitive boolean]'
No gratuitous runtime incompatibility, it will only break compat and
punish early browser impelmentations.
John-David Dalton wrote:
Doing this naively will both impose unacceptable overhead*and* allow
type-confusion attacks.
I'm talking about adding back the wording that ES5.x currently has
allowing host objects to set their own internal [[Class]] (or whatever
it's new incarnation is) value.
Hi Mark,
When I wrote:
Please resist the urge to clean things up.
I did not mean resist at all costs. Just resist the
low-reward/high-compat-break-risk temptations. HTH,
/be
___
es-discuss mailing list
es-discuss@mozilla.org
On Sat, Jan 28, 2012 at 7:13 PM, Jeff Walden jwalden...@mit.edu wrote:
At least, if you consider |with| and |eval| fun (and who doesn't?):
js var x = outer; function f() { with({ x: 17 }) eval(var x); return
x; } typeof f()
undefined
This seems to be the behavior in every engine out
On Sat, Jan 28, 2012 at 5:54 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
Under the open issues for Quasi Literals,
http://wiki.ecmascript.org/doku.php?id=harmony:quasis#nesting , the
topic of nesting is brought up.
After implementing Quasi Literals in Traceur it is clear that
@/be
This too may be ok if not observable. But you wrote:
You could simplify it by making `NativeArray = Array` and
`NativeRegExp = RegExp` and so on. Then you could drop the Tags
table and extending the range of Object#toString is as easy as adding
a custom [[NativeBrand]] property value.
On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich bren...@mozilla.org wrote:
I don't think we should change __proto__ unnecessarily from current
implementations, including making it an accessor. Neither JSC nor
SpiderMonkey does that.
We do need the ability to delete it, so it should live on
On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich bren...@mozilla.org wrote:
I don't think we should change __proto__ unnecessarily from current
implementations, including making it an accessor. Neither JSC nor
SpiderMonkey does that.
We do need the ability to delete it, so it should live on
On Sat, Jan 28, 2012 at 5:21 PM, Gavin Barraclough barraclo...@apple.comwrote:
[...]
Given this is __proto__ we're talking about, maybe it just isn't worth
being overly specific here?
How about we just specify that:
* The only permissible way to modify an object's [[Prototype]] is
On Sat, Jan 28, 2012 at 6:58 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I don't think we would ever want to expose __proto__ as an accessor
property on Object.prototype as that would expose set/get functions that
would also have the capabilities of __proto__ without being associated
@MarkM
A host object is an object supplied by the host environment to
complete the execution environment of ECMAScript.
Sigh. This came up last time as well, and as participants in the spec
writing process our only excuse was That text isn't normative. That
doesn't really excuse it from
Mark S. Miller wrote:
I think the least confusing way forward may be to drop the terms host
object and native object completely from ES6.
+∞!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On 01/28/2012 08:20 PM, felix wrote:
It seems to me the behavior you observe conforms to spec.
Hmm, yes, on second look I think you're right. I guess I was reading overfast
and missed the variable environment/lexical environment distinction there.
That, or it's been too long since I looked
Mark S. Miller wrote:
On Sat, Jan 28, 2012 at 12:16 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
I don't think we should change __proto__ unnecessarily from
current implementations, including making it an accessor. Neither
JSC nor SpiderMonkey does that.
46 matches
Mail list logo
