2011/10/19 David Herman dher...@mozilla.com
What's the [[Value]] property? I'm not sure I understand.
Er, sorry, [[PrimitiveValue]]. (It was called [[Value]] in Edition 3.)
Section 8.6.2, Table 9.
I see. Yes, I can imagine that if p is a direct proxy wrapping a Date
instance, then
On 19 October 2011 05:08, David Herman dher...@mozilla.com wrote:
It’s still as easy to create such “virtual” proxies: just pass a fresh
empty object (or perhaps even null?)
Please, make it null. So much more pleasant (and avoids needless
allocation).
(The only downside of allowing null to
Le 19/10/2011 10:57, Andreas Rossberg a écrit :
On 19 October 2011 05:08, David Hermandher...@mozilla.com wrote:
It’s still as easy to create such “virtual” proxies: just pass a fresh
empty object (or perhaps even null?)
Please, make it null. So much more pleasant (and avoids needless
Hello.
I wrote new ECMA262 5.1 full support engine iv / lv5 in C++.
This is highly inspired from JSC, V8 and SpiderMonkey. (especially JSC)
https://github.com/Constellation/iv
This aims at most precise engine to ECMA262 5.1 specification. (like
the great engine,)
I read ECMA262 and wanted
2011/10/19 David Bruant bruan...@gmail.com
Le 19/10/2011 10:57, Andreas Rossberg a écrit :
If I understand the proposal correctly, you cannot avoid the
allocation, because the target is used as a backing store for fixed
properties.
Indeed. The target is merged with the fixedProps of the
ES3 (and ES5) defines these grammar productions:
MemberExpression :
PrimaryExpression
FunctionExpression
MemberExpression [ Expression ]
MemberExpression . IdentifierName
new MemberExpression Arguments
PrimaryExpression :
this
Identifier
Literal
ArrayLiteral
These are all good points. I'm not sure (1) is worth bringing back in all the
we won't let you say things you can't enforce complexity, but (2) is maybe
non-obvious enough not to be worth it. I'm backing off my please make it null
position now. :) It actually seems pretty reasonable just to
Then we can continue to use . and [] to access properties and use @[] to
access data structure elements. I wouldn’t like the asymmetry introduced by
using [] for the latter task.
this is plausible and certainly a way to avoid outrage about defining [ ].
I'll have to stew on it a bit to
On Wed, Oct 19, 2011 at 8:30 AM, Axel Rauschmayer a...@rauschma.de wrote:
Then we can continue to use . and [] to access properties and use @[] to
access data structure elements. I wouldn’t like the asymmetry introduced by
using [] for the latter task.
this is plausible and certainly a
Thus, there really are two alternatives:
1. Changing [] in the above manner plus object@nameObject for accessing
properties (as you suggested).
2. [] stays as it is and @[] (perhaps there is something slicker, e.g. .[])
is introduced for collections and dicts.
Instead of creating a lot
On Wed, Oct 19, 2011 at 9:12 AM, Axel Rauschmayer a...@rauschma.de wrote:
Thus, there really are two alternatives:
1. Changing [] in the above manner plus object@nameObject for accessing
properties (as you suggested).
2. [] stays as it is and @[] (perhaps there is something slicker, e.g.
The topic of single-frame continuations has been discussed here before,
with the current state of ES.next moving towards generators that are
based on and similar to Mozilla's JS1.7 implementation. Generators are a
powerful addition to the language and welcome (at least by me). However,
I
On Wed, Oct 19, 2011 at 9:52 AM, Axel Rauschmayer a...@rauschma.de wrote:
What are you suggesting? A new primitive? Or a subtype of Object? I don’t
think there is a third alternative to those two.
I am suggesting that typeof return collection when the RHS defines a new
semantic for []
Problem: How do you invoke methods on table?
table.tellAxel = function() {alert('here is a method call');};
table['tellAxel'] = function() {alert('here is a function entry);};
table.tellAxel(); // here is a method call
table['tellAxel'].apply(null,[]); // here is a function entry
On Wed, Oct 19, 2011 at 10:27 AM, Axel Rauschmayer a...@rauschma.de wrote:
Problem: How do you invoke methods on table?
table.tellAxel = function() {alert('here is a method call');};
table['tellAxel'] = function() {alert('here is a function entry);};
table.tellAxel(); // here is a method
So you are arguing in favor of approach #1, right?
No, I am arguing against changing the meaning of [] on 'object'.
Then I would make “your” Map a subtype of Object. typeof is currently best
limited to primitives (and to distinguishing them from objects), so
introducing a new result
This is a really great idea, Kris! A few comments inline...
On Wed, Oct 19, 2011 at 1:11 PM, Kris Zyp k...@sitepen.com wrote:
The topic of single-frame continuations has been discussed here before,
with the current state of ES.next moving towards generators that are based
on and similar to
ES3 (and ES5) defines these grammar productions:
MemberExpression :
PrimaryExpression
FunctionExpression
MemberExpression [ Expression ]
MemberExpression . IdentifierName
new MemberExpression Arguments
PrimaryExpression :
this
Identifier
Literal
ArrayLiteral
below
On Oct 19, 2011, at 10:44 AM, John J Barton wrote:
On Wed, Oct 19, 2011 at 10:27 AM, Axel Rauschmayer a...@rauschma.de wrote:
Problem: How do you invoke methods on table?
table.tellAxel = function() {alert('here is a method call');};
table['tellAxel'] = function() {alert('here is
(sorry about any duplicates like this that show up. I seem to have had posting
delays yesterday that resulted in duplicate postings)
Allen
On Oct 18, 2011, at 6:31 PM, Allen Wirfs-Brock wrote:
ES3 (and ES5) defines these grammar productions:
MemberExpression :
PrimaryExpression
It isn't clear what you guys are arguing about.
Under my proposal,
old objects and old code operating upon old objects continue to work as it
always has.
new objects continue to work like old objects unless the new objects have
been explicitly defined to have collection access behavior
1. Deprecate [] for property access in non-collection objects and use methods
such as Object.getProperty(name) and Object.setProperty(name, value), instead.
Additionally:
Object.prototype.operator[]get = function (name) {
return Object.getProperty(name);
}
Object.prototype.operator[]set =
On Oct 19, 2011, at 12:07 PM, Axel Rauschmayer wrote:
1. Deprecate [] for property access in non-collection objects and use
methods such as Object.getProperty(name) and Object.setProperty(name,
value), instead.
Additionally:
Object.prototype.operator[]get = function (name) {
Kris Zyp wrote:
I believe that the overwhelming need that is continually and
constantly expressed and felt in the JS community in terms of handling
asynchronous activity is fundamentally a cry for top-down controlled
single-frame continuations (obviously not always stated in such terms,
2011/10/6 Andreas Rossberg rossb...@google.com
A related nit: even for freeze and friends, the restriction on
recursive fix is NOT enough as currently stated in the proxy
semantics. Consider:
--
var handler = {
get fix() { Object.seal(p); return {} }
}
var p =
On 10/19/2011 12:29 PM, Dean Landolt wrote:
This is a really great idea, Kris! A few comments inline...
[snip]
If the value is not an object with a then property that is a
function, the operand value is the immediate result of the
evaluation of the yield expression and execution
On Wed, Oct 19, 2011 at 11:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
below
On Oct 19, 2011, at 10:44 AM, John J Barton wrote:
On Wed, Oct 19, 2011 at 10:27 AM, Axel Rauschmayer a...@rauschma.dewrote:
Problem: How do you invoke methods on table?
table.tellAxel = function()
In principal, that's how it should work. In practice, since we have to deal
with objects that don't inherit from Object.prototype I suspect it is best to
leave the fall back behavior as part of the definition of the operator.
Cool. I don’t care how the details are handled, as long as there
On Oct 19, 2011, at 12:55 PM, Eric Jacobs wrote:
Kris Zyp wrote:
I believe that the overwhelming need that is continually and
constantly expressed and felt in the JS community in terms of handling
asynchronous activity is fundamentally a cry for top-down controlled
single-frame
On Oct 19, 2011, at 10:11 AM, Kris Zyp wrote:
The topic of single-frame continuations has been discussed here before, with
the current state of ES.next moving towards generators that are based on and
similar to Mozilla's JS1.7 implementation. Generators are a powerful addition
to the
On Oct 19, 2011, at 2:34 PM, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync XHR)
JS has run-to-completion execution model now. You can model
assert_invariants();
f();
assert_invariants_not_affected_by_f_etc();
Contrast with generators,
On Oct 19, 2011, at 8:16 AM, Allen Wirfs-Brock wrote:
ES3 (and ES5) defines these grammar productions:
MemberExpression :
PrimaryExpression
FunctionExpression
MemberExpression [ Expression ]
MemberExpression . IdentifierName
new MemberExpression Arguments
On Oct 19, 2011, at 2:53 PM, Brendan Eich wrote:
On Oct 19, 2011, at 8:16 AM, Allen Wirfs-Brock wrote:
Function expressions were added in ES3. Were they just added at the wrong
place in the grammar?
Thanks for raising this, I keep forgetting to.
Oddly enough, SpiderMonkey always
On Oct 19, 2011, at 3:29 PM, Allen Wirfs-Brock wrote:
On Oct 19, 2011, at 2:53 PM, Brendan Eich wrote:
On Oct 19, 2011, at 8:16 AM, Allen Wirfs-Brock wrote:
Function expressions were added in ES3. Were they just added at the wrong
place in the grammar?
Thanks for raising this, I
34 matches
Mail list logo
