We had this in ES4, together with the provision that you could have multiple
arguments between the [], so you could define data structures that can be
addressed as:
matrix2d[x, y]
As in here, this would default to the ES5 semantics on objects that don't have
the new [] proxy handler.
[1] http://wiki.ecmascript.org/doku.php?id=strawman:dicts [D.H. already
mentioned that this proposal does not reflect his current thinking, so beware]
FWIW, I don't really know what my current thinking is. :)
Dave
___
es-discuss mailing list
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.
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
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
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) {
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
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
the member names and they can be used as open ended data collections where
property names are used as key values for accessing data in the
On Mon, Oct 17, 2011 at 4:30 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
the member names and they can be used as open ended data
YES! This is the most exciting proposals I've seen in years. I'm so excited!
With this we would be able to implement Array and all those pesky DOM
collections without a hitch [*]. I think it might even allow sub
classing Array if Array was reimlemented using this mechanism.
[*] What of
Dot access has always been nothing more than sugar -- a strict subset of the
domain of legal property names. This subset excludes private names just as it
excludes a whole range of strings, and for the same reason (insufficient
syntax support). Arguing for syntax support is one thing -- and
(Dave Herman has another way to say this: [ ] and . can be viewed as
operating on two separate property name spaces, but for legacy/normal ES
objects those namespaces are collapsed into a single shared namespace.)
Lest the above be construed as a tacit approval on my part... ;)
IMHO the
- Pro: This conflation makes JavaScript very flexible.
- Con: We only get poor man’s maps via objects. Most other dynamic languages
(Python, Ruby, Groovy) allow any value as a key.
- Con: Name collisions between map entries and properties is a constant
source of trouble. For example, I
On Oct 17, 2011, at 2:38 PM, Dean Landolt wrote:
On Mon, Oct 17, 2011 at 4:30 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
On Oct 17, 2011, at 3:34 PM, David Herman wrote:
IMHO the single property name space of es-current is a feature, not a bug.
I tend to agree. There are expressibility problems, too. For example, if you
have an object that uses . for its API and [] for some other data, then what
do you
This would seem to be a fundamental conflict between using [ ] to access
private properties and using [ ] as a special collection element accessor
syntax. You might take this as problem with using [ ] as a collection
accessor or as a discovering that using [ ] as a private property access
I agree 100% percent with the observations, but not with the solution.
Shouldn’t this be done the other way around, by introducing a new way of
accessing map elements? For example:
map@[key]
map.[key]
Then we can continue to use . and [] to access properties and use @[] to
On Oct 17, 2011, at 3:32 PM, Erik Arvidsson wrote:
YES! This is the most exciting proposals I've seen in years. I'm so excited!
Thanks...
What started me thinking along this line was noticing how Dart handles [ ] as a
dynamically dispatched method. It isn't the first language to do so and C#
On Oct 17, 2011, at 4:16 PM, Axel Rauschmayer wrote:
I agree 100% percent with the observations, but not with the solution.
Shouldn’t this be done the other way around, by introducing a new way of
accessing map elements? For example:
map@[key]
map.[key]
Then we can continue
I suspect it's not nearly so rare as you think. For example, it just showed up
in Tom and Mark's new proxy proposal:
The protect trap is called on Object.{freeze,seal,preventExtensions}(aProxy).
The operation argument is a string identifying the corresponding operation
(“freeze”, “seal”,
On Oct 17, 2011, at 5:18 PM, David Herman wrote:
I suspect it's not nearly so rare as you think. For example, it just showed
up in Tom and Mark's new proxy proposal:
The protect trap is called on
Object.{freeze,seal,preventExtensions}(aProxy). The operation argument is a
string
On Oct 17, 2011, at 5:24 PM, Brendan Eich wrote:
On Oct 17, 2011, at 5:18 PM, David Herman wrote:
I suspect it's not nearly so rare as you think. For example, it just showed
up in Tom and Mark's new proxy proposal:
The protect trap is called on
31 matches
Mail list logo
