From: VK on
On Nov 1, 1:15 am, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
wrote:
> VK <schools_r...(a)yahoo.com> writes:
> >> However, the language's syntax rules give you three ways to name a
> >> property in an object literal, viz :
>
> >>  as an Identifier
> >>  as a  StringLiteral
> >>  as a  NumericLiteral
>
> > No, the language gives you only one option to name a property in an
> > object literal, this is a string literal.
>
> No! It is a string *value*!

http://en.wikipedia.org/wiki/String_literal#Bracketed_delimiters

Why is it important to say "string literal" and not "string value"?
Because this is the point that distinguishes strings here:
var s = 'foobar';
and say here:
var s = 'foo'+'bar';
other words literal and expressions / return values / whatever which
may well be string values.

> There are three ways to specify that string value:
>  Identifier, string literal and number literal.
>
> Please distinguish literals (syntax) from values (semantics)!

I pretty much understood the point expressed by you and by other
participants. In JavaScript an identifier is whatever is treated on
the parsing stage by identifier parsing rules. Harris' variation:
identifiers that identify string literals resulting from the parsing.
foo identifies property name "foo"
0144 or 0x64 or 100.0 or 100 identify property name "100"
etc.
As I said such "philosophic mechanicism" may be understood after some
efforts, but I am strongly opposing to any attempt to say that this
has anything to do with any common programming terminology or
thinking.

P.S.
var obj = new Object;
obj[0144] = true;
obj[-100] = true;
for (p in obj) {window.alert(p);}
Rather than create some really special programming terms and almost
programming schools just take that the guys were too busy with other
stuff when making JavaScript1.2 so just added implicit constructors
with syntax shortcut atop already rather weird per-property
constructor so the system is as it is but of course without any "non-
identifying identifiers" and stuff.

P.S.S. Yet of course some regulars already might have a set of
definitions for say
obj[-100] = true;
without any "implicit quoting"

But why not just KISS ? Only to be not like everyone?


From: Lasse Reichstein Nielsen on
VK <schools_ring(a)yahoo.com> writes:

> On Nov 1, 1:15�am, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
> wrote:
>> VK <schools_r...(a)yahoo.com> writes:
>> > No, the language gives you only one option to name a property in an
>> > object literal, this is a string literal.
>>
>> No! It is a string *value*!
>
> http://en.wikipedia.org/wiki/String_literal#Bracketed_delimiters
>
> Why is it important to say "string literal" and not "string value"?

Because they are different and live in different domains. Evaluating
expression syntax creates values. A string literal syntax evaluates
to a string value.

> Because this is the point that distinguishes strings here:
> var s = 'foobar';
> and say here:
> var s = 'foo'+'bar';
> other words literal and expressions / return values / whatever which
> may well be string values.

Indeed. A string literal is a piece of syntax.

In the above 'foobar' is a string literal (eight characters, including
the single quotes), which is also an expression. It evaluates to the
six-character string consisting of the letters f, o, o, b, a and r.

And 'foo' + 'bar' is an expression using the '+' operator on two
sub-expressions that are each string literals. It evaluates, in a
number of steps, to a string value indistinguishable from that of
'foobar'.

The representation of a string value is unknown to the user,
it merely acts as a member of the String type when accessed by the
program.
The representation of a string literal is a sequence of characters
in the program source.


Keys in objects are string values.
In object literals, these string values can be represented by either
string literals, identifiers or number literals.


You keep comming back to unquoted literals and numbers as being merely
shorthands for writing string literals without the quotes.
Thinking of how the language was developed, I don't think that was the
reasoning (without actually knowing it, not being B.Eich).

In JavaScript, objects fills several roles:
- They are object oriented objects, with fields and methods known
to the programmer. These are typically accessed using
identifiers, e.g.:
o.method(o.property), array.substring(array.length - 2)
- They are arrays, indexed by integers, including number literals:
a[42] or a[numbervar]
- They are generic maps from strings to values, indexed using
strings, including string literals:
m["foo"] or m[stringvar]

It makes sense that object literals can be specified in all of these
ways too, even though the underlying object implementation uses
strings for all properties.

var o = { get : function() { return this.x; },
set : function(x) { this.x = x; },
x : undefined };
var a = { 0 : 42, 1 : 13, length: 2 };
var m = {"foo" : o,
"bar" : a };

From the language point of view, they all make their own sense for
differt types of objects, not just as shorthands for map entries.

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: Sherm Pendley on
VK <schools_ring(a)yahoo.com> writes:

> Why is it important to say "string literal" and not "string value"?

For the same reason it's important to say "orange" and not "apple"
when you are in fact talking about oranges.

> But why not just KISS?

Simple is good. Over-simplifying to the point of being incorrect is not.

sherm--
From: John G Harris on
On Sun, 1 Nov 2009 at 07:39:30, in comp.lang.javascript, VK wrote:

<snip>
>Harris' variation:
>identifiers that identify string literals resulting from the parsing.
<snip>

Not my variation; it's your variation. I suggested you were using
'identifier' as an alias for 'property name', the thing that identifies
a property when the program runs.

Inside the compiler the property name won't be held as a string literal.
If the program is written in C++ then it will most likely be held as a
member of the wstring class; if in C then it will most likely be held in
an array of wchar, ending with a 0x0000 character.

John
--
John Harris
From: VK on
John G Harris wrote:
> I suggested you were using
> 'identifier' as an alias for 'property name',
> the thing that identifies
> a property when the program runs.

Well, this doesn't work because it doesn't have sense in the
programming. I altered it a bit to be if not too useful then at least
sensual:

The identifier foo identifies a variable foo in the context of Global
or function scope. In an implicit object constructor if used in the
position of the property name it identifies string literal "foo" - or
globally: any valid identifier in the position of the property name in
an implicit object constructor identifies string literal consisting of
the character sequence forming the said identifier.

This is an extremely weird approach of course but at least it has some
sense within the human programming science.

Another option - other than claiming your quoted statement be a lore
from the Alpha Centauri programming school :) - is to stop writing
"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary
capitalization and proper reference so then make it clear that you are
not talking about a programming entity but about a charcode sequence
defined by such and such formal criteria. Then:

Any valid ECMA 262 3rd.ed. Identifier in the source code in the
position of the property name in an implicit object constructor is
used as string literal consisting of the character sequence forming
the said Identifier.

This is an extremely weird approach as well but OK, everyone goes to
the hell by his own road :)


P.S. I see that everyone tried to ignore my little homework so humbly
repeating it :)

var foo = 'bar';
var obj = new Object;
obj[foo] = true;
obj[-100] = true;
for (p in obj) {window.alert(p);} // "bar", "-100"

1) What is the difference between a Harris' "parsing stage ECMA 262
3rd.ed. Identifier" on and an "identifier" in the casual programming
sense in the program itself.

2) Comment on the second result without using words "to quote" and
"quotes"