Re: Negative indices for arrays
On 12.11.2010 1:17, Allen Wirfs-Brock wrote: -Original Message- From: Dmitry A. Soshnikov [mailto:dmitry.soshni...@gmail.com] ... Yeah, it's possible to make this thing generic, though maybe also good only for arrays. Need to more discuss, think. There isn't actually all that much difference between array instances and non-array objects with array index properties. ES5 went in the direction of making sure that array functions all worked on arbitrary objects. I don't think we would want to go backwards on that. Yeah, however, I think it's mostly not about generic methods, but about overloaded [[Get]] / [[Put]]. And in ES3 and ES5 overloaded [[Put]] / [[DefineOwnProperty]] is not generic but special for arrays. The same I assume this feature is special for arrays. Really, I don't see any big issues with backward compats. They are so minimal that may be ignored. ... this would break any code that currently uses property names like -1. I repeat, we tried to find and remind at least _one_ more-less serious use-case where negaitve indices where used in the old code with array -- and can't. Do you know any? It will be useful if you show. Anybody who is using an object (possibly an array instance) as a hash table with signed integer keys That's another case. Of course, if we'll consider the other objects, then -1 may be used. But, repeat, this feature (at least with the syntax `a[-n]`) should be considered first/only for arrays. Another thing I agree we may want to see in JS a generic such a feature, then the alternative syntax as `a[* - 1]` may be the case. That, repeat, will bring also a sugar for `a.push(10)` as `a[*] = 10`. This isn't just syntactic sugar. It also has all sorts of complications relating to the basic property access semantics. Getting this right would probably require a major redesign of ECMAScript object/property semantics in a manner that I wouldn't anticipate happening anytime soon. Thanks. Though, I don't see a bit changes (how you like to described all in dark colors :)). At maximum (if not generic) -- only [[Get]] of arrays and strings will be affected. And presumably [[Put]] and as some sort of dynamic parsing of string property names and for generic object support check for a length property, etc. Yep, sure. So, do I understand correctly that you are against this feature and don't like it? (Just another question -- are you aware that it used in Python, Ruby, Perl, Coffee, other langs?) I have no problem with this feature as it appears in other languages. I'm just saying that it doesn't appear to fit well with JavaScript's property semantics. But what are suggesting at the same time? What's your meaning -- whether JS needs a some sugar for taking elements (ok, let's say) of a sequence starting-from-the-end or not? Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 1:21, Allen Wirfs-Brock wrote: -Original Message- From: Peter van der Zee [mailto:e...@qfox.nl] ... I guess I would like -n to map to length-n, but I'm not sure whether it's worth the cost described above. After all, it's just sugar. Like Oliver also said. Like everybody on this list understands _what_ it is. This isn't just sugar, it is a deep semantic change to the interpretation of property names As I see it: 1. if to consider only for arrays -- it's a minimal semantics changes and minimal backward compats. 2. if to make it generic, we need another syntax. What do you suggest? Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 2:25, David Herman wrote: If harmony would introduce this syntax guarded under a new script type, there would at least be no danger of breaking the web (existing scripts). That sounds like an interop nightmare -- you're talking about forking the Array type between language versions. Keep in mind that non-Harmony and Harmony code will be able to interact in the same page. Agreed, it will be very hard to combine different semantics on the same page; it's not the case. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
2010/11/12 Dmitry A. Soshnikov dmitry.soshni...@gmail.com: What do you suggest? I suggest you monkey patch a get method on the Array prototype and forget trying to get the language semantics changed. The people who implement the language have made their opinions clear and as of this post that includes V8. -- Erik Corry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 2:40, Brendan Eich wrote:
I agree with Dave, Allen, and Oliver
That's OK.
I consider several variants also. As Allen mentioned, if it will be a
generic thing, then `foo[-n]` may break an old code (and then we need
another syntax e.g. a[* - 1] -- if need at all then!). OTOH, if only for
arrays -- I don't see any big _real practical_ issues.
that we should not just change indexing under Harmony script-type opt-in.
Note also that Python, at least, has a more elaborate system of slicing that
has evolved over the years. I added slice in the Netscape 4 era, which made it
into ES3 and has the desired negative index behavior, but other additions from
that era (some from Perl!) do not match, and anyway, the
array-index-is-a-property-name ship had sailed in 1995.
Of course it had sailed. But the thing is nobody (?) on that ship used
negative-array-index in old code -- in a some more-less serious _real
practical_ application. So it may be re-borrowed and put on the next
ship. However, not necessary in this view -- a[-1]. If generic, -- with
another syntax.
If we were to develop a generic slice proposal with new syntax, then I think it
would be crazy not to follow Python's (and ES3-5's slice method's) lead and
support negative indexing. This would not break existing code because it would
happen only with new syntax and new functions or methods.
Absolutely.
The obvious slice syntax is a[i:j] for a slice of a from index i up to but not
including index j, with negative indexes supported as from the end, and with
indexes on either side of : optional, defaulting as in Python.
If : is problematic we could try CoffeeScript's .., but .. and ... as well as .
in the language may be too much. The syntax is not as important as the
semantics at this point, but one more syntax observation:
The [:] syntax fits in Python, where a[-1] is the last element of the sequence
a.
But since we don't want to make that change to JS arrays,
So, can we stop at this point? I mean -- if we really don't want this
changes, then the question may be closed, I guess. Just acknowledge it.
this slice syntax is not so attractive. It will mislead Python folks into
using negative indexes with property accesses as well as with slices.
Yeah, true. Though, maybe nevertheless to completely port Python's
slicing for arrays? ;P I liked this idea. But -- only for arrays, not
generic then. Unfortunatelly, it may break current generic slice --
`[].slice.call({0:1, 1:2, length:2}, -1)[0]` // 2.
Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one would
hope).
How that? Coffee borrows its .. (including higher index) and ...
(excluding higher index) from Ruby:
Ruby:
a = [1, 2, 3, 4]
a[-1] # 4
a[0..2] # [1,2,3]
a[0...2] # [1,2]
(need to say, that for me .. and ... should be logically inverted: i.e.
... should include, and .. -- exclude).
This seems much more promising for Harmony than new slice or from-the-end
indexing syntax, since we already have Array and String slice methods that do
the right thing with negative indexes.
Yes, regarding slice -- yes. And moreover, they are generic.
We have String charAt/charCodeAt but part of the appeal of slicing and
negative indexing is how they work on all sequence types in Python.
An Array and String get method that takes an index, which can be negative,
would complement slice. Array would want a set or put method too. Names need
tuning, but they ought to be short.
Absolutely.
/be
On Nov 11, 2010, at 3:25 PM, David Herman wrote:
If harmony would introduce this syntax guarded under a new script type, there
would at least be no danger of breaking the web (existing scripts).
That sounds like an interop nightmare -- you're talking about forking the Array
type between language versions. Keep in mind that non-Harmony and Harmony code
will be able to interact in the same page.
Dave
___
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
Re: Negative indices for arrays
On 12.11.2010 12:01, Erik Corry wrote: 2010/11/12 Dmitry A. Soshnikovdmitry.soshni...@gmail.com: What do you suggest? I suggest you monkey patch a get method on the Array prototype and forget trying to get the language semantics changed. The people who implement the language have made their opinions clear and as of this post that includes V8. Sure. And already have done (as mentioned in the initial message -- http://bit.ly/9KBxzl) -- with using proxies it's very easy to implement. Unfortunately (or fortunately -- it depends), not on `Array.prototype` (since I cannot replace it with a proxy, because of [[Configurable]] / [[Writable]] false), but with using `Array.new` semantics. It may be even used. Though, without a big wide-spreading (as in other langs), it will be just an academic curiosity without practical usage. Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On Nov 12, 2010, at 1:01 AM, Dmitry A. Soshnikov wrote:
I consider several variants also. As Allen mentioned, if it will be a generic
thing, then `foo[-n]` may break an old code (and then we need another syntax
e.g. a[* - 1] -- if need at all then!). OTOH, if only for arrays -- I don't
see any big _real practical_ issues.
It is dangerous to make assertions based on wishes, instead of gathering data
(see below).
that we should not just change indexing under Harmony script-type opt-in.
Note also that Python, at least, has a more elaborate system of slicing that
has evolved over the years. I added slice in the Netscape 4 era, which made
it into ES3 and has the desired negative index behavior, but other additions
from that era (some from Perl!) do not match, and anyway, the
array-index-is-a-property-name ship had sailed in 1995.
Of course it had sailed. But the thing is nobody (?) on that ship used
negative-array-index in old code -- in a some more-less serious _real
practical_ application.
You do keep asserting that. :-|
Though, maybe nevertheless to completely port Python's slicing for arrays? ;P
I liked this idea. But -- only for arrays, not generic then. Unfortunatelly,
it may break current generic slice -- `[].slice.call({0:1, 1:2, length:2},
-1)[0]` // 2.
Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one
would hope).
How that?
I was referring to slice.
Ok, data: I added logging code to detect whenever an array is accessed via a
negative index to my custom http://hg.mozilla.org/tracemonkey Firefox build.
Here after a few minutes of browsing is the log file, piped through sort -u
(there are many repeated entries):
file:///Users/brendaneich/Hacking/hg.mozilla.org/tracemonkey/OBJ/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js:1762:-1
http://i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1
http://i.zdnet.com/js/mootools-core-more.js:3:-1
http://l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.jsmetro/contentcarousel/contentcarousel_0.1.40.jsmetro/contentcarousel/contentcarouseladserved_0.1.6.jsmetro/uiplugins/toolbar_bridge_service_0.1.18.jsmetro/uiplugins/tooltip_service_0.1.47.jsmetro/uiplugins/sortable_service_0.1.20.jsmetro/pa/pautil_0.1.4.jsmetro/pa/palist_0.1.23.jsmetro/pa/pa_0.1.218.jsmetro2/multimedia/multimedia_0.0.6.jsmetro/batchload/batchload_0.1.7.js:7:-1
I'll keep this browser running for a bit, but it is clear somebody used
negative array indexes. And it would be no fun finding such dynamic occurrences
when porting if we made negative indexes work as in Python in Harmony.
In general, taking ES5 strict code into Harmony should not require porting,
other than removing any dependencies on global variable vs global object
property aliasing.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
Brendan, thanks for the analysis and tests, possibly it's useful. Also,
I think that a proposal can look more like a proposal (and not like I'm
very want to include something into the language, and other members
resist it), I'm not sure we need to prove something in this case. If
everybody on the lists have decided that this is not needed for
ECMAScript -- that's completely OK.
(Below some small additions)
On 12.11.2010 18:40, Brendan Eich wrote:
On Nov 12, 2010, at 1:01 AM, Dmitry A. Soshnikov wrote:
I consider several variants also. As Allen mentioned, if it will be a generic
thing, then `foo[-n]` may break an old code (and then we need another syntax
e.g. a[* - 1] -- if need at all then!). OTOH, if only for arrays -- I don't see
any big _real practical_ issues.
It is dangerous to make assertions based on wishes, instead of gathering data
(see below).
Sure.
that we should not just change indexing under Harmony script-type opt-in.
Note also that Python, at least, has a more elaborate system of slicing that
has evolved over the years. I added slice in the Netscape 4 era, which made it
into ES3 and has the desired negative index behavior, but other additions from
that era (some from Perl!) do not match, and anyway, the
array-index-is-a-property-name ship had sailed in 1995.
Of course it had sailed. But the thing is nobody (?) on that ship used
negative-array-index in old code -- in a some more-less serious _real
practical_ application.
You do keep asserting that. :-|
Of course. Though, we may say that neither Allen (including Erick from
V8), nor Oliver didn't even asserted. Just some abstract dramatic,
critical breaking of the old code. But in real, I didn't see it. Your
tests with logging maybe prove something, but hardly it's an absolute
and real results. Anyway, it's something.
Though, maybe nevertheless to completely port Python's slicing for arrays? ;P I
liked this idea. But -- only for arrays, not generic then. Unfortunatelly, it
may break current generic slice -- `[].slice.call({0:1, 1:2, length:2}, -1)[0]`
// 2.
Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one would
hope).
How that?
I was referring to slice.
Hm... These are slices:
a = [1, 2, 3, 4]
a[0..2] # 1,2,3
a[1..-1] # 2,3,4
a[-1..-1] # 4
a[-1] # the same, 4
Btw, in ES, slice being able to slice:
a.slice(-2, -1); // [3]
unable to slice:
a.slice(-2, -1); // []
and requires:
a.slice(-1)[0]; // 4
but this is -- JFTR.
Ok, data: I added logging code to detect whenever an array is accessed via a
negative index to my custom http://hg.mozilla.org/tracemonkey Firefox build.
Here after a few minutes of browsing is the log file, piped through sort -u
(there are many repeated entries):
file:///Users/brendaneich/Hacking/hg.mozilla.org/tracemonkey/OBJ/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js:1762:-1
http://i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1
http://i.zdnet.com/js/mootools-core-more.js:3:-1
http://l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.jsmetro/contentcarousel/contentcarousel_0.1.40.jsmetro/contentcarousel/contentcarouseladserved_0.1.6.jsmetro/uiplugins/toolbar_bridge_service_0.1.18.jsmetro/uiplugins/tooltip_service_0.1.47.jsmetro/uiplugins/sortable_service_0.1.20.jsmetro/pa/pautil_0.1.4.jsmetro/pa/palist_0.1.23.jsmetro/pa/pa_0.1.218.jsmetro2/multimedia/multimedia_0.0.6.jsmetro/batchload/batchload_0.1.7.js:7:-1
I'll keep this browser running for a bit, but it is clear somebody used
negative array indexes. And it would be no fun finding such dynamic occurrences when
porting if we made negative indexes work as in Python in Harmony.
Maybe they tried to apply exactly Python's semantics while were testing?
:D But seriously, yep, the test may say something.
In general, taking ES5 strict code into Harmony should not require porting,
other than removing any dependencies on global variable vs global object
property aliasing.
OK, so since all are against, I think the proposal (if is not required
hard) may be canceled.
Thanks again.
Dmitry.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 13.11.2010 0:25, Dmitry A. Soshnikov wrote: unable to slice: a.slice(-2, -1); // [] Sorry, typo; meant a.slice(-1, -1); [] Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
the D language handles this by having the names '$' and 'length' be the length of the array, within the scope of a [] subscript, so you can say something like a[$-1]. '$' is already too widely used in js, but maybe something like '_' would work. say, if there's no declaration of _ in scope, then _ within [] is the length of the array. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 13.11.2010 0:52, felix wrote: the D language handles this by having the names '$' and 'length' be the length of the array, within the scope of a [] subscript, so you can say something like a[$-1]. '$' is already too widely used in js, but maybe something like '_' would work. say, if there's no declaration of _ in scope, then _ within [] is the length of the array. $ and _ -- both are valid identifiers which may already have values. Though, $ is used in regexp and isn't confused with the same name identifier. With the same success any other could be accepted. But, as said -- everyone on this list do not see the need. Dmitry. ___ 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: Negative indices for arrays
I would have liked negative indexes for bracket-indexing from the end, and I
suspect others who knew in their bones that it's too incompatible of a change
would too -- we just knew it was not going to be a non-breaking change.
It's very hard to change subtle features that the Web comes to depend on. I've
only seen building better mousetraps, leading people away from the old trap,
work over time. It's not a speedy process, especially if the subtle feature is
not a misfeature (but people disagree on this difference -- 'with' is still
with us, some people actually defend and use it).
/be
On Nov 12, 2010, at 1:25 PM, Dmitry A. Soshnikov wrote:
Brendan, thanks for the analysis and tests, possibly it's useful. Also, I
think that a proposal can look more like a proposal (and not like I'm very
want to include something into the language, and other members resist it),
I'm not sure we need to prove something in this case. If everybody on the
lists have decided that this is not needed for ECMAScript -- that's
completely OK.
(Below some small additions)
On 12.11.2010 18:40, Brendan Eich wrote:
On Nov 12, 2010, at 1:01 AM, Dmitry A. Soshnikov wrote:
I consider several variants also. As Allen mentioned, if it will be a
generic thing, then `foo[-n]` may break an old code (and then we need
another syntax e.g. a[* - 1] -- if need at all then!). OTOH, if only for
arrays -- I don't see any big _real practical_ issues.
It is dangerous to make assertions based on wishes, instead of gathering
data (see below).
Sure.
that we should not just change indexing under Harmony script-type opt-in.
Note also that Python, at least, has a more elaborate system of slicing
that has evolved over the years. I added slice in the Netscape 4 era,
which made it into ES3 and has the desired negative index behavior, but
other additions from that era (some from Perl!) do not match, and anyway,
the array-index-is-a-property-name ship had sailed in 1995.
Of course it had sailed. But the thing is nobody (?) on that ship used
negative-array-index in old code -- in a some more-less serious _real
practical_ application.
You do keep asserting that. :-|
Of course. Though, we may say that neither Allen (including Erick from V8),
nor Oliver didn't even asserted. Just some abstract dramatic, critical
breaking of the old code. But in real, I didn't see it. Your tests with
logging maybe prove something, but hardly it's an absolute and real results.
Anyway, it's something.
Though, maybe nevertheless to completely port Python's slicing for arrays?
;P I liked this idea. But -- only for arrays, not generic then.
Unfortunatelly, it may break current generic slice -- `[].slice.call({0:1,
1:2, length:2}, -1)[0]` // 2.
Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one
would hope).
How that?
I was referring to slice.
Hm... These are slices:
a = [1, 2, 3, 4]
a[0..2] # 1,2,3
a[1..-1] # 2,3,4
a[-1..-1] # 4
a[-1] # the same, 4
Btw, in ES, slice being able to slice:
a.slice(-2, -1); // [3]
unable to slice:
a.slice(-2, -1); // []
and requires:
a.slice(-1)[0]; // 4
but this is -- JFTR.
Ok, data: I added logging code to detect whenever an array is accessed via a
negative index to my custom http://hg.mozilla.org/tracemonkey Firefox build.
Here after a few minutes of browsing is the log file, piped through sort -u
(there are many repeated entries):
file:///Users/brendaneich/Hacking/hg.mozilla.org/tracemonkey/OBJ/dist/MinefieldDebug.app/Contents/MacOS/components/nsSessionStore.js:1762:-1
http://i.i.com.com/cnwk.1d/html/rb/js/tron/oreo.moo.rb.combined.js:6:-1
http://i.zdnet.com/js/mootools-core-more.js:3:-1
http://l.yimg.com/a/combo?metro/tuc/tuc_outboxlite_0.0.29.jsmetro/contentcarousel/contentcarousel_0.1.40.jsmetro/contentcarousel/contentcarouseladserved_0.1.6.jsmetro/uiplugins/toolbar_bridge_service_0.1.18.jsmetro/uiplugins/tooltip_service_0.1.47.jsmetro/uiplugins/sortable_service_0.1.20.jsmetro/pa/pautil_0.1.4.jsmetro/pa/palist_0.1.23.jsmetro/pa/pa_0.1.218.jsmetro2/multimedia/multimedia_0.0.6.jsmetro/batchload/batchload_0.1.7.js:7:-1
I'll keep this browser running for a bit, but it is clear somebody used
negative array indexes. And it would be no fun finding such dynamic
occurrences when porting if we made negative indexes work as in Python in
Harmony.
Maybe they tried to apply exactly Python's semantics while were testing? :D
But seriously, yep, the test may say something.
In general, taking ES5 strict code into Harmony should not require porting,
other than removing any dependencies on global variable vs global object
property aliasing.
OK, so since all are against, I think the proposal (if is not required hard)
may be canceled.
Thanks again.
Dmitry.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Re: Negative indices for arrays
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote: There was previous indirect mention, were Brendan agreed that Harmony needs such a semantics for arrays Sorry, forgot the link https://mail.mozilla.org/pipermail/es-discuss/2010-May/05.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote: Toughs? Funny typo :D Sorry. Thoughts? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
Actually, I'm still not sure myself whether I want this semantics in JS
for arrays. I remember one case (some simple math task) when I was
needed a[-1] and was glad that JS supports it -- I used `for (var i =
-2; i 10; i++) a[i]`, and it was very elegant decision at that moment.
There is also one lack (?) with decreasing counter loop (brought in
discussion on Twitter), e.g.:
var a = [1, 2, 3], i = a.length;
while (v = a[--i]) {
print(i, v)
}
that brings: 2,3 1,2 0,1 -1,3 -2,2 -3,1
i.e. double enumeration with this semantics. But formally, it's not a
bug, but a feature -- both Python and Ruby have the same semantics in
such a `while` case.
Another reason I'm still no sure about a[-1] is that JS (in contrast
with the same Python and Ruby) has no stratification of normal
properties -- via dot notation, and subscription properties -- via
square bracket notation. I mentioned this in previous mentioned thread.
And from this viewpoint, probably it's not good that o[-1] means exactly
-1 and a[-1] means a[`last`]. Don't know.
Want both -- and (probably sometimes needed) -1, and sugar for [`last`].
Though, repeat, since ES5 brought special semantics for subscription of
strings, i.e. abc[0] is a, maybe it worth to make another sugar for
arrays too? Btw, if yes, it will touch strings too.
Dmitry.
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,
How likely (based on backward compats) that Harmony will support
Pythonic negative indices for arrays? Ruby supports them too. There
was previous indirect mention, were Brendan agreed that Harmony needs
such a semantics for arrays, however, that discussion wasn't formed to
something concrete.
Recently, there was the same discussion in CoffeeScript's tracker --
https://github.com/jashkenas/coffee-script/issues#issue/827 . Since
Coffee uses JavaScript as its lower level, there were proposals to
provide an alternative syntax for this (e.g. a[* - 1], where * means
a.length, allowing this feature to be generic), though, I'm not sure
this exact syntax is needed for ES. However, I mentioned there, that
if Harmony itself will support this feature in Python's/Ruby's
semantics, then Coffee won't need an alternative thing.
Currently, this feature may be easily implemented using proxies:
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js
(example),
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js
(implementation), however possibly it's good to have this semantics
for objects with [[Class]] Array as native. I think it's acceptable,
since we already have such alternative semantics for String objects.
Toughs?
Dmitry.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On Nov 11, 2010, at 11:30 AM, Dmitry A. Soshnikov wrote:
OTOH, negative indices, are even not array indices. I.e.
var a = [1,2];
a[-1] = 0;
print(a); // 1,2
print(a.length); // 2
From this viewpoint -- for what are they? Seems again, `-n` notations for
arrays and strings is useful as a from the end-sugar. So now I may propose
it.
They're property names, what you're suggesting would be a fairly dramatic
change in behaviour and I would be concerned about it causing site breakages.
I can easily imagine code that did:
var someArray = ..;
var i = someArray.length;
while(v = someArray[--i]) { .. do something... }
Which would now be wrong.
Likewise bugs that lead to code doing a[-1]=foo; would change from being safe
to modifying the content of the actual array values.
I'm sure I've had this discussion before, the fundamental problem is that ES
does not really distinguish between dot and bracket property access, whereas
afaik python does (i don't know about ruby).
--Oliver
On 11.11.2010 21:26, Dmitry A. Soshnikov wrote:
Actually, I'm still not sure myself whether I want this semantics in JS for
arrays. I remember one case (some simple math task) when I was needed a[-1]
and was glad that JS supports it -- I used `for (var i = -2; i 10; i++)
a[i]`, and it was very elegant decision at that moment.
There is also one lack (?) with decreasing counter loop (brought in
discussion on Twitter), e.g.:
var a = [1, 2, 3], i = a.length;
while (v = a[--i]) {
print(i, v)
}
that brings: 2,3 1,2 0,1 -1,3 -2,2 -3,1
i.e. double enumeration with this semantics. But formally, it's not a bug,
but a feature -- both Python and Ruby have the same semantics in such a
`while` case.
Another reason I'm still no sure about a[-1] is that JS (in contrast with
the same Python and Ruby) has no stratification of normal properties -- via
dot notation, and subscription properties -- via square bracket notation. I
mentioned this in previous mentioned thread. And from this viewpoint,
probably it's not good that o[-1] means exactly -1 and a[-1] means
a[`last`]. Don't know.
Want both -- and (probably sometimes needed) -1, and sugar for [`last`].
Though, repeat, since ES5 brought special semantics for subscription of
strings, i.e. abc[0] is a, maybe it worth to make another sugar for
arrays too? Btw, if yes, it will touch strings too.
Dmitry.
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,
How likely (based on backward compats) that Harmony will support Pythonic
negative indices for arrays? Ruby supports them too. There was previous
indirect mention, were Brendan agreed that Harmony needs such a semantics
for arrays, however, that discussion wasn't formed to something concrete.
Recently, there was the same discussion in CoffeeScript's tracker --
https://github.com/jashkenas/coffee-script/issues#issue/827 . Since Coffee
uses JavaScript as its lower level, there were proposals to provide an
alternative syntax for this (e.g. a[* - 1], where * means a.length,
allowing this feature to be generic), though, I'm not sure this exact
syntax is needed for ES. However, I mentioned there, that if Harmony itself
will support this feature in Python's/Ruby's semantics, then Coffee won't
need an alternative thing.
Currently, this feature may be easily implemented using proxies:
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js
(example),
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/array-negative-indices.js
(implementation), however possibly it's good to have this semantics for
objects with [[Class]] Array as native. I think it's acceptable, since we
already have such alternative semantics for String objects.
Toughs?
Dmitry.
___
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: Negative indices for arrays
On 11 Nov 2010, at 19:30, Dmitry A. Soshnikov wrote: OTOH, negative indices, are even not array indices. I.e. var a = [1,2]; a[-1] = 0; print(a); // 1,2 print(a.length); // 2 From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a from the end-sugar. So now I may propose it. Yes please, both perl and ruby have it and I often find myself instinctively typing it in JS. -ash ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 11.11.2010 22:39, Ash Berlin wrote: On 11 Nov 2010, at 19:30, Dmitry A. Soshnikov wrote: OTOH, negative indices, are even not array indices. I.e. var a = [1,2]; a[-1] = 0; print(a); // 1,2 print(a.length); // 2 From this viewpoint -- for what are they? Seems again, `-n` notations for arrays and strings is useful as a from the end-sugar. So now I may propose it. Yes please, both perl and ruby have it and I often find myself instinctively typing it in JS. And Python too (from langs I know). Other probably also. -ash ___ 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: Negative indices for arrays
On 11.11.2010 22:39, Oliver Hunt wrote:
On Nov 11, 2010, at 11:30 AM, Dmitry A. Soshnikov wrote:
OTOH, negative indices, are even not array indices. I.e.
var a = [1,2];
a[-1] = 0;
print(a); // 1,2
print(a.length); // 2
From this viewpoint -- for what are they? Seems again, `-n` notations
for arrays and strings is useful as a from the end-sugar. So now I
may propose it.
They're property names,
Thanks, I perfectly know what are they. And said myself that there is an
issue that there's no stratification of properties/methods (by dot
notation) and hash keys/array indexes (by square bracket notation). But
it doesn't change fact that ES spec has concept of an array index -- a
property name which is ToString(ToUInt32(name)) === name. Now I propose
also a virtual array index which is ToString(ToInt32(name)) === name.
what you're suggesting would be a fairly dramatic change in behaviour
and I would be concerned about it causing site breakages.
No any dramatic changes. ES5 standardized strings indices. Caused it
dramatic changes? Nope. And this sugar (which is available in many
langs) also won't I think.
I can easily imagine code that did:
var someArray = ..;
var i = someArray.length;
while(v = someArray[--i]) { .. do something... }
Didn't I show the same code in the previous message? Yeah, we discussed
it on Twitter.
Which would now be wrong.
And concluded that this is a feature, not a bug. Both, Python and Ruby
have the same behavior for such a `while` case. So what? It doesn't
change the fact that this is still a useful sugar.
Likewise bugs that lead to code doing a[-1]=foo; would change from
being safe to modifying the content of the actual array values.
In `-n` virtual property semantics it will modify array value --
starting from the end.
I'm sure I've had this discussion before, the fundamental problem is
that ES does not really distinguish between dot and bracket property
access, whereas afaik python does (i don't know about ruby).
Yes, I mentioned it myself several times (in articles and including
several topics in es-discuss). Yes, Python distinguish. Ruby too. But
from your position, ES already has some lacks then. E.g. Object.keys()
-- what does it mean? What kind of keys you have found here? Or maybe
`Object.getOwnPropertyNames()` ?
Still ES has concept of an array index (separating it from all other
properties), I think a virtual array index is also good.
Dmitry.
--Oliver
On 11.11.2010 21:26, Dmitry A. Soshnikov wrote:
Actually, I'm still not sure myself whether I want this semantics in
JS for arrays. I remember one case (some simple math task) when I
was needed a[-1] and was glad that JS supports it -- I used `for
(var i = -2; i 10; i++) a[i]`, and it was very elegant decision at
that moment.
There is also one lack (?) with decreasing counter loop (brought in
discussion on Twitter), e.g.:
var a = [1, 2, 3], i = a.length;
while (v = a[--i]) {
print(i, v)
}
that brings: 2,3 1,2 0,1 -1,3 -2,2 -3,1
i.e. double enumeration with this semantics. But formally, it's not
a bug, but a feature -- both Python and Ruby have the same semantics
in such a `while` case.
Another reason I'm still no sure about a[-1] is that JS (in contrast
with the same Python and Ruby) has no stratification of normal
properties -- via dot notation, and subscription properties -- via
square bracket notation. I mentioned this in previous mentioned
thread. And from this viewpoint, probably it's not good that o[-1]
means exactly -1 and a[-1] means a[`last`]. Don't know.
Want both -- and (probably sometimes needed) -1, and sugar for
[`last`].
Though, repeat, since ES5 brought special semantics for subscription
of strings, i.e. abc[0] is a, maybe it worth to make another
sugar for arrays too? Btw, if yes, it will touch strings too.
Dmitry.
On 11.11.2010 13:24, Dmitry A. Soshnikov wrote:
Hello,
How likely (based on backward compats) that Harmony will support
Pythonic negative indices for arrays? Ruby supports them too. There
was previous indirect mention, were Brendan agreed that Harmony
needs such a semantics for arrays, however, that discussion wasn't
formed to something concrete.
Recently, there was the same discussion in CoffeeScript's tracker
-- https://github.com/jashkenas/coffee-script/issues#issue/827 .
Since Coffee uses JavaScript as its lower level, there were
proposals to provide an alternative syntax for this (e.g. a[* - 1],
where * means a.length, allowing this feature to be generic),
though, I'm not sure this exact syntax is needed for ES. However, I
mentioned there, that if Harmony itself will support this feature
in Python's/Ruby's semantics, then Coffee won't need an alternative
thing.
Currently, this feature may be easily implemented using proxies:
https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/array-negative-indices.js
(example),
RE: Negative indices for arrays
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Dmitry A. Soshnikov
...
Yes, I mentioned it myself several times (in articles and including several
topics in es-discuss). Yes, Python distinguish. Ruby too. But from your
position, ES already has some lacks then. E.g. Object.keys() -- what does it
mean? What kind of keys you have found here? Or maybe
`Object.getOwnPropertyNames()`?
Object.keys and Object.getOwnProertyNames are both precisely defined by ES5.
keys returns the names of all non-enumerable own properties of an object.
getOwnPropertyNames returns the names of all own properties.
For example look at the results of Object.keys(new String('abc')) and
Object.getOwnPropertyNames(new String('abc')) on an ES5 conforming
implementation.
...
Still ES has concept of an array index (separating it from all other
properties), I think a virtual array index is also good.
Not really. ES5 does not generally consider array elements or array index
property names as separate or different from other properties or property
names. According to the ES5 spec. (15.4) array index is a term used to talk
about property names that conform to a specific requirement
(ToString(ToUint32(name) ) === name and ToUint32(name) !==2^32-1).
Instances of the Array constructor has special semantics for defining and
updating array index properties. In addition, some of Array.prototype
functions that perform arithmetic on array index property names do it in a
manner that ensures results are also array index names. Other than that ES5
doesn't define any special semantics for array index properties.
Implementations are free to optimize how they store array index properties (and
many implementations do) but they are also free to optimize the storage of any
property as long as the optimization maintains the observable ES5 semantics.
[from a different message]
ES5 brought special semantics for subscription of strings, i.e. abc[0] is
a, maybe it worth to make another sugar for arrays too?
Actually, all that ES5 did was specify that String objects (not string values)
have non-writable, non-configurable properties corresponding to the individual
characters of the encapsulated string value. abc[0] is really equivalent to
(new String(abc))[0]
Btw, if yes, it will touch strings too.
Presumably, any object with a 'length' property.
As Oliver said, this would break any code that currently uses property names
like -1. This isn't just syntactic sugar. It also has all sorts of
complications relating to the basic property access semantics. Getting this
right would probably require a major redesign of ECMAScript object/property
semantics in a manner that I wouldn't anticipate happening anytime soon.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 0:07, Allen Wirfs-Brock wrote:
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Dmitry A. Soshnikov
...
Yes, I mentioned it myself several times (in articles and including several topics in
es-discuss). Yes, Python distinguish. Ruby too. But from your position, ES already has
some lacks then. E.g. Object.keys() -- what does it mean? What kind of keys
you have found here? Or maybe `Object.getOwnPropertyNames()`?
Object.keys and Object.getOwnProertyNames are both precisely defined by ES5.
keys returns the names of all non-enumerable own properties of an object.
getOwnPropertyNames returns the names of all own properties.
I think it should went without saying that I meant what kind of keys
have you found here if there are only properties?. Just to underline
that ES already has in some aspects some alternative meanings but not
just a property name (though, still keeping _only_ property names
concept).
Once again, thanks for the clarifications, but I perfectly understand
and am aware about the difference. ES-3 and ES-5 specs are out, everyone
can read it. So I did already.
For example look at the results of Object.keys(new String('abc')) and
Object.getOwnPropertyNames(new String('abc')) on an ES5 conforming
implementation.
...
Still ES has concept of an array index (separating it from all other properties), I
think a virtual array index is also good.
Not really. ES5 does not generally consider array elements or array index property
names as separate or different from other properties or property names. According to the ES5 spec.
(15.4) array index is a term used to talk about property names that conform to a
specific requirement (ToString(ToUint32(name) ) === name and ToUint32(name) !==2^32-1).
Thanks again, I'm (was) aware about it.
Instances of the Array constructor has special semantics for defining and updating array index
properties. In addition, some of Array.prototype functions that perform arithmetic on array index property
names do it in a manner that ensures results are also array index names. Other than that ES5 doesn't
define any special semantics for array index properties. Implementations are free to optimize how they
store array index properties (and many implementations do) but they are also free to optimize the storage of any
property as long as the optimization maintains the observable ES5 semantics.
About this too, thanks.
And I propose for array instances in addition to have special semantics
for handling of virtual array index properties. That is
ToString(ToInt32(name)) === name with handling correctly ranges.
[from a different message]
ES5 brought special semantics for subscription of strings, i.e. abc[0] is
a, maybe it worth to make another sugar for arrays too?
Actually, all that ES5 did was specify that String objects (not string values) have non-writable,
non-configurable properties corresponding to the individual characters of the encapsulated string
value. abc[0] is really equivalent to (new String(abc))[0]
Yep, thanks, I know how and when and why a primitive is converted to an
object and what's going on after that. But still it doesn't cancel the
fact that ES5 brought an alternative semantics which could/can break old
code where var s = new String(foo); s[0] = x; had different semantics.
Btw, if yes, it will touch strings too.
Presumably, any object with a 'length' property.
Yeah, it's possible to make this thing generic, though maybe also good
only for arrays. Need to more discuss, think.
As Oliver said,
I appreciated it, but let us discuss the case. And exactly your meaning.
this would break any code that currently uses property names like -1.
I repeat, we tried to find and remind at least _one_ more-less serious
use-case where negaitve indices where used in the old code with array --
and can't. Do you know any? It will be useful if you show.
This isn't just syntactic sugar. It also has all sorts of complications
relating to the basic property access semantics. Getting this right would
probably require a major redesign of ECMAScript object/property semantics in a
manner that I wouldn't anticipate happening anytime soon.
Thanks. Though, I don't see a bit changes (how you like to described all
in dark colors :)). At maximum (if not generic) -- only [[Get]] of
arrays and strings will be affected.
So, do I understand correctly that you are against this feature and
don't like it? (Just another question -- are you aware that it used in
Python, Ruby, Perl, Coffee, other langs?)
Dmitry.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Negative indices for arrays
If harmony would introduce this syntax guarded under a new script type, there
would at least be no danger of breaking the web (existing scripts).
However, negative array indexes might cause confusion when doing so
implicitly. If you asume array indexes are just properties it'll be hard to
debug a snippet like `while (x = arr[--i]) ...` (not my own example). While it
wouldn't be my preferred way of doing this, it's still valid and will cause
very
obscure and hard to debug problems.
I guess I would like -n to map to length-n, but I'm not sure whether it's worth
the cost described above. After all, it's just sugar.
- peter
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Dmitry A. Soshnikov
..
Yes, I mentioned it myself several times (in articles and
including several topics in es-discuss). Yes, Python distinguish.
Ruby too. But from your position, ES already has some lacks then.
E.g. Object.keys() -- what does it mean? What kind of keys you
have found here? Or maybe `Object.getOwnPropertyNames()`?
Object.keys and Object.getOwnProertyNames are both precisely
defined by ES5. keys returns the names of all non-enumerable own
properties of an object. getOwnPropertyNames returns the names of
all own properties.
For example look at the results of Object.keys(new String('abc'))
and Object.getOwnPropertyNames(new String('abc')) on an ES5
conforming implementation.
..
Still ES has concept of an array index (separating it from all
other properties), I think a virtual array index is also good.
Not really. ES5 does not generally consider array elements or
array index property names as separate or different from other
properties or property names. According to the ES5 spec. (15.4)
array index is a term used to talk about property names that
conform to a specific requirement (ToString(ToUint32(name) ) ===
name and ToUint32(name) !==2^32-1).
Instances of the Array constructor has special semantics for
defining and updating array index properties. In addition, some
of Array.prototype functions that perform arithmetic on array
index property names do it in a manner that ensures results are
also array index names. Other than that ES5 doesn't define any
special semantics for array index properties. Implementations
are free to optimize how they store array index properties (and
many implementations do) but they are also free to optimize the
storage of any property as long as the optimization maintains the
observable ES5 semantics.
[from a different message]
ES5 brought special semantics for subscription of strings, i.e.
abc[0] is a, maybe it worth to make another sugar for arrays
too?
Actually, all that ES5 did was specify that String objects (not
string values) have non-writable, non-configurable properties
corresponding to the individual characters of the encapsulated
string value. abc[0] is really equivalent to (new
String(abc))[0]
Btw, if yes, it will touch strings too.
Presumably, any object with a 'length' property.
As Oliver said, this would break any code that currently uses
property names like -1. This isn't just syntactic sugar. It also
has all sorts of complications relating to the basic property
access semantics. Getting this right would probably require a
major redesign of ECMAScript object/property semantics in a manner
that I wouldn't anticipate happening anytime soon.
Allen
___
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: Negative indices for arrays
So, do I understand correctly that you are against this feature and don't like it? (Just another question -- are you aware that it used in Python, Ruby, Perl, Coffee, other langs?) The fact that other languages have a feature is not relevant, the problem is the drastic change to semantics of property access. In a way that is incompatible with existing behaviour. It is not syntactic sugar. Syntactic sugar takes something that would fail to run in the past, and makes it do something helpful instead. You want to take a syntax that does one thing, and change its behaviour entirely. --Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
On 12.11.2010 0:42, Peter van der Zee wrote:
If harmony would introduce this syntax guarded under a new script type, there
would at least be no danger of breaking the web (existing scripts).
I don't think it means that using script type=harmony we may do
everything (i.e. completely different syntax and skin).
However, negative array indexes might cause confusion when doing so
implicitly. If you asume array indexes are just properties it'll be hard to
debug a snippet like `while (x = arr[--i]) ...` (not my own example).
Why this example is repeated already third time here? ;) Yes, we aware
about it, and as said, it's a feature, not a bug.
While it
wouldn't be my preferred way of doing this, it's still valid and will cause very
obscure and hard to debug problems.
I guess I would like -n to map to length-n, but I'm not sure whether it's worth
the cost described above. After all, it's just sugar.
But again, it's not a bug. Both, Ruby and Python has the same semantics
in such case at the same time having `-n` as a sugar:
Ruby:
a = [1, 2, 3];
a[-1] # 3
i = 2
while (v = a[i]) do
print i, v
i -= 1
end
Result: 2,3 1,2 1,0 -1,3 -2,2 -3,0
Python:
a = [1, 2, 3]
a[-1] # 3
i = 2
while a[i]:
print(i, a[i])
i = i - 1
Result: 2,3 1,2 1,0 -1,3 -2,2 -3,0
- peter
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Dmitry A. Soshnikov
..
Yes, I mentioned it myself several times (in articles and
including several topics in es-discuss). Yes, Python distinguish.
Ruby too. But from your position, ES already has some lacks then.
E.g. Object.keys() -- what does it mean? What kind of keys you
have found here? Or maybe `Object.getOwnPropertyNames()`?
Object.keys and Object.getOwnProertyNames are both precisely
defined by ES5. keys returns the names of all non-enumerable own
properties of an object. getOwnPropertyNames returns the names of
all own properties.
For example look at the results of Object.keys(new String('abc'))
and Object.getOwnPropertyNames(new String('abc')) on an ES5
conforming implementation.
..
Still ES has concept of an array index (separating it from all
other properties), I think a virtual array index is also good.
Not really. ES5 does not generally consider array elements or
array index property names as separate or different from other
properties or property names. According to the ES5 spec. (15.4)
array index is a term used to talk about property names that
conform to a specific requirement (ToString(ToUint32(name) ) ===
name and ToUint32(name) !==2^32-1).
Instances of the Array constructor has special semantics for
defining and updating array index properties. In addition, some
of Array.prototype functions that perform arithmetic on array
index property names do it in a manner that ensures results are
also array index names. Other than that ES5 doesn't define any
special semantics for array index properties. Implementations
are free to optimize how they store array index properties (and
many implementations do) but they are also free to optimize the
storage of any property as long as the optimization maintains the
observable ES5 semantics.
[from a different message]
ES5 brought special semantics for subscription of strings, i.e.
abc[0] is a, maybe it worth to make another sugar for arrays
too?
Actually, all that ES5 did was specify that String objects (not
string values) have non-writable, non-configurable properties
corresponding to the individual characters of the encapsulated
string value. abc[0] is really equivalent to (new
String(abc))[0]
Btw, if yes, it will touch strings too.
Presumably, any object with a 'length' property.
As Oliver said, this would break any code that currently uses
property names like -1. This isn't just syntactic sugar. It also
has all sorts of complications relating to the basic property
access semantics. Getting this right would probably require a
major redesign of ECMAScript object/property semantics in a manner
that I wouldn't anticipate happening anytime soon.
Allen
___
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: Negative indices for arrays
On 12.11.2010 0:47, Oliver Hunt wrote: So, do I understand correctly that you are against this feature and don't like it? (Just another question -- are you aware that it used in Python, Ruby, Perl, Coffee, other langs?) The fact that other languages have a feature is not relevant, the problem is the drastic change to semantics of property access. In a way that is incompatible with existing behaviour. It is not syntactic sugar. Syntactic sugar takes something that would fail to run in the past, and makes it do something helpful instead. You want to take a syntax that does one thing, and change its behaviour entirely. I understand what I want and what I propose. OK, so, do I understand that you also (as Allen) against this feature and don't like it? Another question -- still, can you remind at least one more-less serious use-case when `-n` were heavily used with arrays? I repeat, we tried -- and couldn't. Maybe you will, it will be useful -- to analyze whether we need such a sugar or not and what will it break, but not just abstract talks about it will dramatically crash everything old. Thanks. Dmitry. --Oliver ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Negative indices for arrays
-Original Message- From: Dmitry A. Soshnikov [mailto:dmitry.soshni...@gmail.com] ... Yeah, it's possible to make this thing generic, though maybe also good only for arrays. Need to more discuss, think. There isn't actually all that much difference between array instances and non-array objects with array index properties. ES5 went in the direction of making sure that array functions all worked on arbitrary objects. I don't think we would want to go backwards on that. ... this would break any code that currently uses property names like -1. I repeat, we tried to find and remind at least _one_ more-less serious use-case where negaitve indices where used in the old code with array -- and can't. Do you know any? It will be useful if you show. Anybody who is using an object (possibly an array instance) as a hash table with signed integer keys This isn't just syntactic sugar. It also has all sorts of complications relating to the basic property access semantics. Getting this right would probably require a major redesign of ECMAScript object/property semantics in a manner that I wouldn't anticipate happening anytime soon. Thanks. Though, I don't see a bit changes (how you like to described all in dark colors :)). At maximum (if not generic) -- only [[Get]] of arrays and strings will be affected. And presumably [[Put]] and as some sort of dynamic parsing of string property names and for generic object support check for a length property, etc. So, do I understand correctly that you are against this feature and don't like it? (Just another question -- are you aware that it used in Python, Ruby, Perl, Coffee, other langs?) I have no problem with this feature as it appears in other languages. I'm just saying that it doesn't appear to fit well with JavaScript's property semantics. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Negative indices for arrays
-Original Message- From: Peter van der Zee [mailto:e...@qfox.nl] ... I guess I would like -n to map to length-n, but I'm not sure whether it's worth the cost described above. After all, it's just sugar. Like Oliver also said. This isn't just sugar, it is a deep semantic change to the interpretation of property names ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
If harmony would introduce this syntax guarded under a new script type, there would at least be no danger of breaking the web (existing scripts). That sounds like an interop nightmare -- you're talking about forking the Array type between language versions. Keep in mind that non-Harmony and Harmony code will be able to interact in the same page. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Negative indices for arrays
I agree with Dave, Allen, and Oliver that we should not just change indexing under Harmony script-type opt-in. Note also that Python, at least, has a more elaborate system of slicing that has evolved over the years. I added slice in the Netscape 4 era, which made it into ES3 and has the desired negative index behavior, but other additions from that era (some from Perl!) do not match, and anyway, the array-index-is-a-property-name ship had sailed in 1995. If we were to develop a generic slice proposal with new syntax, then I think it would be crazy not to follow Python's (and ES3-5's slice method's) lead and support negative indexing. This would not break existing code because it would happen only with new syntax and new functions or methods. The obvious slice syntax is a[i:j] for a slice of a from index i up to but not including index j, with negative indexes supported as from the end, and with indexes on either side of : optional, defaulting as in Python. If : is problematic we could try CoffeeScript's .., but .. and ... as well as . in the language may be too much. The syntax is not as important as the semantics at this point, but one more syntax observation: The [:] syntax fits in Python, where a[-1] is the last element of the sequence a. But since we don't want to make that change to JS arrays, this slice syntax is not so attractive. It will mislead Python folks into using negative indexes with property accesses as well as with slices. Ruby does not dedicate syntax, using methods instead (Smalltalk-y, as one would hope). This seems much more promising for Harmony than new slice or from-the-end indexing syntax, since we already have Array and String slice methods that do the right thing with negative indexes. We have String charAt/charCodeAt but part of the appeal of slicing and negative indexing is how they work on all sequence types in Python. An Array and String get method that takes an index, which can be negative, would complement slice. Array would want a set or put method too. Names need tuning, but they ought to be short. /be On Nov 11, 2010, at 3:25 PM, David Herman wrote: If harmony would introduce this syntax guarded under a new script type, there would at least be no danger of breaking the web (existing scripts). That sounds like an interop nightmare -- you're talking about forking the Array type between language versions. Keep in mind that non-Harmony and Harmony code will be able to interact in the same page. Dave ___ 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
