{ and } in regexps
Hi,
Browsers seem to allow { and } to occur in regexps unescaped, if the
position does not conflict with their use as a quantifier. For example:
/foo|{bar}/
However, ES3 and ES5 forbid this, as PatternCharacter does not include {
or } or any of the other significant punctuation.
Given that every new implementation ends up having to do what all the
existing implementations do, is there any reason for the spec to differ?
Best regards,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function declarations as statements
On Thu, Nov 11, 2010 at 5:37 PM, Garrett Smith wrote:
> On 11/11/10, Michael Day wrote:
> > Hi Brendan and Allen,
> >
> > Thanks for the pointers.
> >
> >> So for Harmony, we are reclaiming function in block (must be a direct
> >> child of a braced block) to bind a block-local name on block entry (so
> >> hoisting lives, but only to top of block -- so you can't emulate with
> var
> >> f = function ...).
> >
> > If we implemented this behaviour now, I think that would be sufficient
> > to make JQuery
>
> Arrogant bunch of lackeys.
>
> and Raphaël work. Here is an example from JQuery that is
> > giving us trouble:
> >
>
> I am now reminded of the logo Allen proposed for ECMAScript.
>
> > if (condition) {
> > var val, props, ... ;
> >
> > function getWH() { ... this is the function ... }
> >
>
> http://bugs.jquery.com/ticket/6788
>
> I've told them about this sort of problem and they just delete the
> comments.
>
> | GarrettS commented on jquery/jquery August 26, 2010
> |
> | The comment has since been removed.
> |
> | GarrettS commented on jquery/jquery August 26, 2010
> |
> | The comment has since been removed.
>
> More reasons why I do not want to have anything to do with javascript.
>
http://bugs.jquery.com/ticket/6788#comment:2
If it sticks, please reconsider ;). Thanks.
>
> Garrett
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function declarations as statements
On 11/11/10, Michael Day wrote:
> Hi Brendan and Allen,
>
> Thanks for the pointers.
>
>> So for Harmony, we are reclaiming function in block (must be a direct
>> child of a braced block) to bind a block-local name on block entry (so
>> hoisting lives, but only to top of block -- so you can't emulate with var
>> f = function ...).
>
> If we implemented this behaviour now, I think that would be sufficient
> to make JQuery
Arrogant bunch of lackeys.
and Raphaël work. Here is an example from JQuery that is
> giving us trouble:
>
I am now reminded of the logo Allen proposed for ECMAScript.
> if (condition) {
> var val, props, ... ;
>
> function getWH() { ... this is the function ... }
>
http://bugs.jquery.com/ticket/6788
I've told them about this sort of problem and they just delete the comments.
| GarrettS commented on jquery/jquery August 26, 2010
|
| The comment has since been removed.
|
| GarrettS commented on jquery/jquery August 26, 2010
|
| The comment has since been removed.
More reasons why I do not want to have anything to do with javascript.
Garrett
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function declarations as statements
On Thu, Nov 11, 2010 at 5:10 PM, Allen Wirfs-Brock <
allen.wirfs-br...@microsoft.com> wrote:
> I believe that would be interoperable as long as each such function is only
> declared and used within a single block. Multiple declarations with the
> same function name in separate blocks wouldn't be interoperable among all
> browsers.
>
Not quite. It will be incompatible with ES5/strict on those ES5
implementations that follow <
http://wiki.ecmascript.org/doku.php?id=conventions:no_non_standard_strict_decls
>.
For the example code you show under the assumptions you state, if you move
the function declaration into the top level of the containing function or
program, then it will be compat with ES5/strict best practice as well, and
still with everything else.
>
> Allen
>
> > -Original Message-
> > From: Michael Day [mailto:mike...@yeslogic.com]
> > Sent: Thursday, November 11, 2010 4:48 PM
> > To: Brendan Eich
> > Cc: ES-Discuss; Allen Wirfs-Brock
> > Subject: Re: Function declarations as statements
> >
> > Hi Brendan and Allen,
> >
> > Thanks for the pointers.
> >
> > > So for Harmony, we are reclaiming function in block (must be a direct
> child of
> > a braced block) to bind a block-local name on block entry (so hoisting
> lives, but
> > only to top of block -- so you can't emulate with var f = function ...).
> >
> > If we implemented this behaviour now, I think that would be sufficient to
> make
> > JQuery and Raphaël work. Here is an example from JQuery that is giving us
> > trouble:
> >
> > if (condition) {
> > var val, props, ... ;
> >
> > function getWH() { ... this is the function ... }
> >
> > if ( elem.offsetWidth !== 0 ) {
> > getWH();
> > } else {
> > jQuery.swap( elem, props, getWH );
> > }
> >
> > return Math.max(0, Math.round(val)); }
> >
> > The getWH() function is declared in the block and only used in the block,
> so if we
> > hoisted the definition to the top of the block there would not be any
> problems
> > with this usage.
> >
> > Best regards,
> >
> > Michael
> >
> > --
> > Print XML with Prince!
> > http://www.princexml.com
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Function declarations as statements
I believe that would be interoperable as long as each such function is only
declared and used within a single block. Multiple declarations with the same
function name in separate blocks wouldn't be interoperable among all browsers.
Allen
> -Original Message-
> From: Michael Day [mailto:mike...@yeslogic.com]
> Sent: Thursday, November 11, 2010 4:48 PM
> To: Brendan Eich
> Cc: ES-Discuss; Allen Wirfs-Brock
> Subject: Re: Function declarations as statements
>
> Hi Brendan and Allen,
>
> Thanks for the pointers.
>
> > So for Harmony, we are reclaiming function in block (must be a direct child
> > of
> a braced block) to bind a block-local name on block entry (so hoisting lives,
> but
> only to top of block -- so you can't emulate with var f = function ...).
>
> If we implemented this behaviour now, I think that would be sufficient to make
> JQuery and Raphaël work. Here is an example from JQuery that is giving us
> trouble:
>
> if (condition) {
> var val, props, ... ;
>
> function getWH() { ... this is the function ... }
>
> if ( elem.offsetWidth !== 0 ) {
> getWH();
> } else {
> jQuery.swap( elem, props, getWH );
> }
>
> return Math.max(0, Math.round(val)); }
>
> The getWH() function is declared in the block and only used in the block, so
> if we
> hoisted the definition to the top of the block there would not be any problems
> with this usage.
>
> Best regards,
>
> Michael
>
> --
> Print XML with Prince!
> http://www.princexml.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function declarations as statements
Hi Brendan and Allen,
Thanks for the pointers.
So for Harmony, we are reclaiming function in block (must be a direct child of
a braced block) to bind a block-local name on block entry (so hoisting lives,
but only to top of block -- so you can't emulate with var f = function ...).
If we implemented this behaviour now, I think that would be sufficient
to make JQuery and Raphaël work. Here is an example from JQuery that is
giving us trouble:
if (condition) {
var val, props, ... ;
function getWH() { ... this is the function ... }
if ( elem.offsetWidth !== 0 ) {
getWH();
} else {
jQuery.swap( elem, props, getWH );
}
return Math.max(0, Math.round(val));
}
The getWH() function is declared in the block and only used in the
block, so if we hoisted the definition to the top of the block there
would not be any problems with this usage.
Best regards,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Function declarations as statements
>From the ES5 spec section 12 statement semantics:
NOTESeveral widely used implementations of ECMAScript are known to support
the use of FunctionDeclaration as a Statement. However there are significant
and irreconcilable variations among the implementations in the semantics
applied to such FunctionDeclarations. Because of these irreconcilable
differences , the use of a FunctionDeclaration as a Statement results in code
that is not reliably portable among implementations. It is recommended that
ECMAScript implementations either disallow this usage of FunctionDeclaration or
issue a warning when such a usage is encountered. Future editions of ECMAScript
may define alternative portable means for declaring functions in a Statement
context.
Also see section on functions in
http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
There seem to be more browsers that treat function declarations in blocks as
straightforward extensions of the function hoisting semantics (unconditionally)
but Firefox does something different.
As I say in the above blog post, you have to have them in a browser but
anything other than trivial usage is unlike to be interoperable.
Allen
> -Original Message-
> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
> boun...@mozilla.org] On Behalf Of Michael Day
> Sent: Thursday, November 11, 2010 3:46 PM
> To: ES-Discuss
> Subject: Function declarations as statements
>
> Hi,
>
> In ECMAScript, function declarations are SourceElements, but not Statements.
> This means that they can only occur at the top level, and may not be nested
> inside a block.
>
> However, browsers support function declarations as statements, and many
> scripts on the web seem to make use of this ability, especially after they
> have
> been minified.
>
> Is there a spec anywhere for how functions as statements should behave?
>
> Can they be rewritten to var + function expression, so that this:
>
> {
> function f() { return 17 }
> }
>
> becomes this:
>
> {
> var f = function() { return 17 }
> }
>
> When implementing non-standard features, it would be nice to do so in a
> standard manner :)
>
> Best regards,
>
> Michael
>
> --
> Print XML with Prince!
> http://www.princexml.com
> ___
> 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: Function declarations as statements
A recurring topic. See:
https://mail.mozilla.org/pipermail/es-discuss/2007-March/003964.html
https://mail.mozilla.org/pipermail/es-discuss/2008-February/005314.html
https://mail.mozilla.org/pipermail/es-discuss/2008-July/006812.html
and probably many others.
There's no common semantics among top five browsers (although IIRC three follow
IE, the #2 by market share did something different long, long ago).
So for Harmony, we are reclaiming function in block (must be a direct child of
a braced block) to bind a block-local name on block entry (so hoisting lives,
but only to top of block -- so you can't emulate with var f = function ...).
/be
On Nov 11, 2010, at 3:46 PM, Michael Day wrote:
> Hi,
>
> In ECMAScript, function declarations are SourceElements, but not Statements.
> This means that they can only occur at the top level, and may not be nested
> inside a block.
>
> However, browsers support function declarations as statements, and many
> scripts on the web seem to make use of this ability, especially after they
> have been minified.
>
> Is there a spec anywhere for how functions as statements should behave?
>
> Can they be rewritten to var + function expression, so that this:
>
> {
>function f() { return 17 }
> }
>
> becomes this:
>
> {
>var f = function() { return 17 }
> }
>
> When implementing non-standard features, it would be nice to do so in a
> standard manner :)
>
> Best regards,
>
> Michael
>
> --
> Print XML with Prince!
> http://www.princexml.com
> ___
> 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
Function declarations as statements
Hi,
In ECMAScript, function declarations are SourceElements, but not
Statements. This means that they can only occur at the top level, and
may not be nested inside a block.
However, browsers support function declarations as statements, and many
scripts on the web seem to make use of this ability, especially after
they have been minified.
Is there a spec anywhere for how functions as statements should behave?
Can they be rewritten to var + function expression, so that this:
{
function f() { return 17 }
}
becomes this:
{
var f = function() { return 17 }
}
When implementing non-standard features, it would be nice to do so in a
standard manner :)
Best regards,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
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
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
> -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
> -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
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
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
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
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
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
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 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),
https://github.com/D
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 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 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
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.
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
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 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
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
Negative indices for arrays
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
