Semantics of "indexed" string access

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Semantics of "indexed" string access

Allen Wirfs-Brock-2

I’ve taken a crack at cleaning up Pratap’s initial specification for supporting direct indexing of strings, eg “abc”[1] yields “b”

 

Here are the semantics that seemed to make sense:

 

s[n]

1)  If s has an own property whose name is the same as the value of n, the value of that property is returned.

2) else If the value of n is convertible to a number that is within the bounds of the string value, return a string containing the corresponding character

3) else if try to resolve n as the name of an inherited property

4) else return undefined.

 

In other words, indexing into a string with a “valid” index returns that appropriate character unless somebody has explicitly defined a property named by that index on the object.

If the “index” is not within the bounds of the string it is treated like a normal property access – If it isn’t defined either locally or on the parent chain the result is undefined.

 

I’ve specified this by “over-riding” the definition of [[GetOwnProperty]] for string instances”.  Note that literal strings as in the example above will have been transformed into objects by the property access semantics of 11.2.1

 

15.5.5.2 [[GetOwnProperty]] (P)

String objects use a variation of the [[GetOwnProperty]] method used for other native ECMAScript objects (8.6.2.1.2).

Assume S is a String object and P is a string.

When the [[GetOwnProperty]] method of S is called with property name P, the following steps are taken:

1.      Call the default [[GetOwnProperty]] method (8.6.2.1.2) with S as the this value and argument P.

2.      If Result(1) is not undefined return Result(1).

3.      If P is not an array index (15.4) , return undefined.

4.      Call ToString, giving S as its argument.

5.      Call ToInteger(P).

6.      Compute the number of characters in Result(4).

7.      If Result(5) is less than 0 or is not less than Result(4), return undefined.

8.      Return a string of length 1, containing one character from Result(4), namely the character at position Result(5), where the first (leftmost) character in Result(4) is considered to be at position 0, the next one at position 1, and so on.

 

 

Is this a reasonable semantics? Does it match what browsers have already implemented?


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Semantics of "indexed" string access

Allen Wirfs-Brock-2

A slightly revised (last two steps) version of the pseudo-code:

 

15.5.5.2 [[GetOwnProperty]] (P)

String objects use a variation of the [[GetOwnProperty]] method used for other native ECMAScript objects (8.6.2.1.2).

Assume S is a String object and P is a string.

When the [[GetOwnProperty]] method of S is called with property name P, the following steps are taken:

1.      Call the default [[GetOwnProperty]] method (8.6.2.1.2) with S as the this value and argument P.

2.      If Result(1) is not undefined return Result(1).

3.      If P is not an array index (15.4) , return undefined.

4.      Call ToString, giving S as its argument.

5.      Call ToInteger(P).

6.      Compute the number of characters in Result(4).

7.      If Result(5) is less than 0 or is not less than Result(4), return undefined.

8.      Create a string of length 1, containing one character from Result(4), namely the character at position Result(5), where the first (leftmost) character in Result(4) is considered to be at position 0, the next one at position 1, and so on.

9.      Return a DDesc with attributes {[[Value]]: Result(8), [[Enumerable]]: false, [[Writeable]]: false, [[Dynamic]]: false]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Allen Wirfs-Brock
Sent: Tuesday, June 24, 2008 5:46 PM
To: [hidden email]; Pratap Lakshman (VJ#SDK)
Cc: [hidden email]
Subject: Semantics of "indexed" string access

 

I’ve taken a crack at cleaning up Pratap’s initial specification for supporting direct indexing of strings, eg “abc”[1] yields “b”

 

Here are the semantics that seemed to make sense:

 

s[n]

1)  If s has an own property whose name is the same as the value of n, the value of that property is returned.

2) else If the value of n is convertible to a number that is within the bounds of the string value, return a string containing the corresponding character

3) else if try to resolve n as the name of an inherited property

4) else return undefined.

 

In other words, indexing into a string with a “valid” index returns that appropriate character unless somebody has explicitly defined a property named by that index on the object.

If the “index” is not within the bounds of the string it is treated like a normal property access – If it isn’t defined either locally or on the parent chain the result is undefined.

 

I’ve specified this by “over-riding” the definition of [[GetOwnProperty]] for string instances”.  Note that literal strings as in the example above will have been transformed into objects by the property access semantics of 11.2.1

 

15.5.5.2 [[GetOwnProperty]] (P)

String objects use a variation of the [[GetOwnProperty]] method used for other native ECMAScript objects (8.6.2.1.2).

Assume S is a String object and P is a string.

When the [[GetOwnProperty]] method of S is called with property name P, the following steps are taken:

10.   Call the default [[GetOwnProperty]] method (8.6.2.1.2) with S as the this value and argument P.

11.   If Result(1) is not undefined return Result(1).

12.   If P is not an array index (15.4) , return undefined.

13.   Call ToString, giving S as its argument.

14.   Call ToInteger(P).

15.   Compute the number of characters in Result(4).

16.   If Result(5) is less than 0 or is not less than Result(4), return undefined.

17.   Return a string of length 1, containing one character from Result(4), namely the character at position Result(5), where the first (leftmost) character in Result(4) is considered to be at position 0, the next one at position 1, and so on.

 

 

Is this a reasonable semantics? Does it match what browsers have already implemented?


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Semantics of "indexed" string access

Maciej Stachowiak
In reply to this post by Allen Wirfs-Brock-2

On Jun 24, 2008, at 5:46 PM, Allen Wirfs-Brock wrote:

I’ve taken a crack at cleaning up Pratap’s initial specification for supporting direct indexing of strings, eg “abc”[1] yields “b”
 
Here are the semantics that seemed to make sense:
 
s[n]
1)  If s has an own property whose name is the same as the value of n, the value of that property is returned.

Since s is a string value, not an object, then it cannot have any own properties. The autogenerated wrapper for s does have some own propertied.

2) else If the value of n is convertible to a number that is within the bounds of the string value, return a string containing the corresponding character
3) else if try to resolve n as the name of an inherited property
4) else return undefined.
 
In other words, indexing into a string with a “valid” index returns that appropriate character unless somebody has explicitly defined a property named by that index on the object.

It is not possible to define a custom property on a string value. On a string object you could.

I would suggest it makes more sense to make index properties of a string act like index properties of an array, but read-only.

Regards,
Maciej


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Semantics of "indexed" string access

Allen Wirfs-Brock-2

Actually, the intent was to support “indexed” access to both string values and string wrapper objects.  I just didn’t make it clear in the example.  The case analysis was intended to apply to both. My reading of section 11.2.1 is that  a string value is to be transformed into an object before any actual property access semantics are applied. Am I wrong?

 

Is the semantics I described really any different from array indexing?  I actually, borrowed some concepts from Array [[Put]] but it is most about maintaining the length invariant. Other than that I didn’t find any array specific property indexing semantics in the ES3 spec.

 

From: Maciej Stachowiak [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 6:21 PM
To: Allen Wirfs-Brock
Cc: [hidden email]; Pratap Lakshman (VJ#SDK); [hidden email]
Subject: Re: Semantics of "indexed" string access

 

 

On Jun 24, 2008, at 5:46 PM, Allen Wirfs-Brock wrote:



I’ve taken a crack at cleaning up Pratap’s initial specification for supporting direct indexing of strings, eg “abc”[1] yields “b”

 

Here are the semantics that seemed to make sense:

 

s[n]

1)  If s has an own property whose name is the same as the value of n, the value of that property is returned.

 

Since s is a string value, not an object, then it cannot have any own properties. The autogenerated wrapper for s does have some own propertied.



2) else If the value of n is convertible to a number that is within the bounds of the string value, return a string containing the corresponding character

3) else if try to resolve n as the name of an inherited property

4) else return undefined.

 

In other words, indexing into a string with a “valid” index returns that appropriate character unless somebody has explicitly defined a property named by that index on the object.

 

It is not possible to define a custom property on a string value. On a string object you could.

 

I would suggest it makes more sense to make index properties of a string act like index properties of an array, but read-only.

 

Regards,

Maciej

 


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Semantics of "indexed" string access

Brendan Eich-2
On Jun 24, 2008, at 6:39 PM, Allen Wirfs-Brock wrote:

Actually, the intent was to support “indexed” access to both string values and string wrapper objects.  I just didn’t make it clear in the example.  The case analysis was intended to apply to both. My reading of section 11.2.1 is that  a string value is to be transformed into an object before any actual property access semantics are applied. Am I wrong?


No, the primitive string type (called "String", confusingly, in ES1-3 when it uses type names) is not an object. It has no internal methods such as [[Get]].

Specifying the indexed unit-string access semantic based on the wrapper String (spelled as in the language) object seems ok. I noted a Result(4) that should have been Result(6) in step 7, via private email to Allen (this type of error is going to happen a lot; count on it).

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Semantics of "indexed" string access

Allen Wirfs-Brock-2

“abc”[1]   Would presumably parse as:

 

MemberExpression [ Expression ]

 

Whose semantic are:

1. Evaluate MemberExpression.

2. Call GetValue(Result(1)).

3. Evaluate Expression.

4. Call GetValue(Result(3)).

5. Call ToObject(Result(2)).

6. Call ToString(Result(4)).

7. Return a value of type Reference whose base object is Result(5) and whose property name is

Result(6).

 

Note that steps 1,2, and 5 amount to ToObject(GetValue(“abc”)).  GetValue(“abc”) yields “abc” so this is really just ToObject(“abc”).  9.9 says ToObject when applied to a s primitive string: “Create a new String object whose [[value]] property is set to the value of the string.”.  That string object becomes the base object of the resulting Reference.  So the literal get converted into an object that  has a [[Get]]

From: Brendan Eich [mailto:[hidden email]]
Sent: Tuesday, June 24, 2008 7:34 PM
To: Allen Wirfs-Brock; Maciej Stachowiak
Cc: [hidden email] x-discuss; Pratap Lakshman (VJ#SDK); [hidden email] es4-discuss
Subject: Re: Semantics of "indexed" string access

 

On Jun 24, 2008, at 6:39 PM, Allen Wirfs-Brock wrote:



Actually, the intent was to support “indexed” access to both string values and string wrapper objects.  I just didn’t make it clear in the example.  The case analysis was intended to apply to both. My reading of section 11.2.1 is that  a string value is to be transformed into an object before any actual property access semantics are applied. Am I wrong?

 

No, the primitive string type (called "String", confusingly, in ES1-3 when it uses type names) is not an object. It has no internal methods such as [[Get]].

 

Specifying the indexed unit-string access semantic based on the wrapper String (spelled as in the language) object seems ok. I noted a Result(4) that should have been Result(6) in step 7, via private email to Allen (this type of error is going to happen a lot; count on it).

 

/be


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Semantics of "indexed" string access

Brendan Eich-2
On Jun 24, 2008, at 9:34 PM, Allen Wirfs-Brock wrote:

Note that steps 1,2, and 5 amount to ToObject(GetValue(“abc”)).  GetValue(“abc”) yields “abc” so this is really just ToObject(“abc”).  9.9 says ToObject when applied to a s primitive string: “Create a new String object whose [[value]] property is set to the value of the string.”.  That string object becomes the base object of the resulting Reference.  So the literal get converted into an object that  has a [[Get]]


Oh, I agree -- that's why I wrote "No" in reply to your "Am I wrong?" :-).

/be

From: Brendan Eich [[hidden email]]
Sent: Tuesday, June 24, 2008 7:34 PM
To: Allen Wirfs-Brock; Maciej Stachowiak
Cc: [hidden email] x-discuss; Pratap Lakshman (VJ#SDK); [hidden email] es4-discuss
Subject: Re: Semantics of "indexed" string access

 

On Jun 24, 2008, at 6:39 PM, Allen Wirfs-Brock wrote:



Actually, the intent was to support “indexed” access to both string values and string wrapper objects.  I just didn’t make it clear in the example.  The case analysis was intended to apply to both. My reading of section 11.2.1 is that  a string value is to be transformed into an object before any actual property access semantics are applied. Am I wrong?

 

No, the primitive string type (called "String", confusingly, in ES1-3 when it uses type names) is not an object. It has no internal methods such as [[Get]].

 

Specifying the indexed unit-string access semantic based on the wrapper String (spelled as in the language) object seems ok. I noted a Result(4) that should have been Result(6) in step 7, via private email to Allen (this type of error is going to happen a lot; count on it).

 

/be

_______________________________________________
Es4-discuss mailing list


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss