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
