Implicit object constructor misinterpretation

On Nov 1, 1:15*am, Lasse Reichstein Nielsen <lrn.unr... (AT) gmail (DOT) com>
wrote:

VK <schools_r... (AT) yahoo (DOT) 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?

VK <schools_ring (AT) yahoo (DOT) com> writes:

On Nov 1, 1:15*am, Lasse Reichstein Nielsen <lrn.unr... (AT) gmail (DOT) com
wrote:
VK <schools_r... (AT) yahoo (DOT) 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'

VK <schools_ring (AT) yahoo (DOT) 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--

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

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"

VK wrote:
<snip>

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.

You are gibbering incoherently again.

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

Yes, and given that example (though what you imagine it to be an example
of is as unclear is you usually leave it) it is extremely unlikely that
you understand that code to start with.

Bracket notation property accessors contain an Expression between their
brackets. That expression is evaluated and the results of evaluating
that expression is type-converted into a string value. Upon assignment
that string value is used as an argument to an object's internal [[Put]]
method, which in the case of an object hat does not already have a
property with the a name that corresponds with the string value, results
in the creation of a property of that object which does.

Now, your Expression is -100 which is not as simple an Expression as
it appears. It is an underrepresented fact that javascript numeric
literals cannot define negative numbers. Which brings us to another
example of something that is a syntax error by specifications but could
easily be accommodated if there was 'implicit quoting' or some form of
'automatic quote insertion' going on. That is:-

var x = {
-1:'somethong'
};

- is a syntax error because the item in the property name context is
none of an Identifier, a string literal or a number literal. It is an
expression. However:-

var x = {
"-1":'somethong'
};

- is fine. yet another example of a truth that is not necessarily
consistent with any notion of 'implicit quoting'.

So the Expression -100 is not a number literal, it is an expression
consisting of the unary minus operator with a numeric literal as its
operand. Thus the evaluation of the expression involves evaluating the
numeric literal to a numeric value, and then applying the unary minus
operator to the result, which is then a negative numeric value.

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

Simplify that is the result of ignoring various aspects of the reality
is only the illusion of simplicity.

Richard.

VK wrote:> Richard Cornford wrote:

You stated that:-
"Object constructor property names are always treated as string
literals, so quotes around them may be omitted in the source
code to speed up typing and/or for a better code readability."

Right.

Agreeing with yourself is a little redundant. I quoted those as examples
of what you actually had stated, where you were trying to make out that
you had actually stated something else entirely. I assume that your
agreement with yourself above represents a re-iteration of your original
statements.

The above is, at best, a speculation about the motivation of the
original creators of object literals, and a speculation about motivation
with regard to something that does not apply to its subject. There is no
sense in "omitted" as not having quotes around the property name part of
an object literal changes the nature of the token.

"due to some parser quirks they may lead to syntax errors"

Right.

Where those "quirks" represent conforming with the syntax rules as
specified for the language that is being parsed.

"do not use the above mentioned syntax shortcut and to use full
syntax with quotes around each property name"

Right.

Where what you are describing as "the full syntax" is nothing but a
sub-set of the syntax for object literals.

There is no meaning to "quotes are omitted". The names used in
object literals are one of Identifiers, string literals, or
numeric literals. String literals are not string literals without
quotes and Identifiers are not Identifiers with them.

That's pretty much points to your regular problem when dealing with
JavaScript, and on a bigger scale - the common problem of many
regulars, getting the base of their wisdom from ECMA262 3rd.ed.
ECMA262 3rd.ed. is an extremely bad source to learn the language

That would depend on what you mean by "learn the language". It is not a
document that will teach anyone how to program with javascript. It is,
however, the optimum document for understanding precisely how the
various constructs used in javascript behave, being the specification
for that behaviour.

Consider the issue in your OP; you can (and you did) speculate about
"broken switch-case" or "not a constructor but a block of statements",
but an examination of the spec shows that the observed behaviour
corresponds with the specified behaviour, and explains the specified
behaviour. Thus avoiding much time wasted in considering irrelevant
alternatives.

because its main purpose is not to explain the language, but
to describe the internal algorithms

ECMA 262 is very explicit about stating that implementations are not
required to implement any of its algorithms, rather they are required to
behave precisely as if they did implement those algorithms. That is, it
is a specification of required behaviour, not a source of instructions
on how that behaviour must be achieved.

so make it possible to
write compliant engines for other than Netscape browsers.

The method the specification adopts in order to facilitate the writing
of compliant engines is to fully define the behaviour expected of such
an engine. The effect of that is to make the document _the_ source for a
full definition of the behaviour expected of an ECMAScript
implementation.

Another obvious function for the specification is to provide a
vocabulary of technical terms for use when talking about javascript that
have the advantage of being objectively defined. Thus, people can talk
about Activation objects, execution contexts, etc, and everyone else can
know what they are talking about with sufficient precision to allow the
truth of such statements to be objectively examined.

Of course, you do not like that latter consideration at all because
little exposes inconsistent/incomplete explanations faster than the use
of precise and objectively defined terminology. You would prefer
everything to be expressed in a form that represents nothing more
certain than the sort of vague mush that is the usual product of your
thought process.

The difference is as between say a Perl user reference and
comments for C libraries used for Perl processor.

Does Perl not have a specification, or do you believe that the people
who really know Perl well do not know/understand that specification?

As the result some regulars know some really refined
internal mechanics, some of which even never did into
any actual implementation,

The question is not whether an implementation implements any particular
algorithm or not, but rather whether it behaves as if it implemented
those algorithms. Failing to behave as if it implements all the
algorithms while claiming to be an ECMA 262 conforming implementation
constitutes a language bug. Unsurprisingly, it is necessary to know (or,
at minimum, refer to) those algorithms in order to be in a position to
declare any particular observed behaviour correct or incorrect.

yet having troubles to get some obviousnesses.

Obviousness is, pretty much by definition, a subjective judgment. You
always have tended to see certain things as obvious where others
perceive then as anything but, and not to see at all some things that
others perceive as obvious.

In the particular and most importantly they are normally having
big time troubles to distinguish *language* features and
*underlaying C-based engine* features

Underlying implementation details are almost completely irrelevant to
any discussion of javascript. We have a language that is designed to be
independent of everything but its host API/Object Model, and a language
that can be implemented in pretty much any other language. There is
certainly little point in considering some "C-based engine" when there
are so many implementations that are not "C-based" such as Rhino being
an implementation in Java, reference implantations being created in ML
and even javascript based implementations such as Narcissus. It is
actually very unlikely that the approaches taken towards an
implementation in C (or C++) is even applicable in any alternative
implementation language.

If anything, it strikes me that it is you who tends to fixate on
irrelevant details of particular implementations.

and consequently having troubles to separate properly
tokenizing, parsing and execution stages,

What evidence do you base that assertion on?

so applying terms and
entities from one stage to another and vice versa.

Allowing Identifiers may be for simplicity (or maybe just
because it seemed like a good idea, or was so obvious that
it was never questioned and so has no motivation). There is
no sense in "omitting" quotes being "allowed" for any reason,
what is allowed is a choice of tokens.

One more time, very slow:

Because it proved so convincing the last half dozen times?

parsed by the rule of an identifier !== to
be an identifier.

For someone who comments of other's failure to "separate properly
tokenizing, parsing and execution stages" it is ironic that you talk of
"parsed by the rule of an identifier" when Identifiers are tokens (see
section 7.5 "Tokens"), and so the product of tokenising not parsing.

In object constructor

You mean object literal?

all key values are string literals,

No they are not. They are Identifiers, string literal or numeric
literals.

explicitly or implicitly quoted.

There is no need for 'implicit quoting', and if it did exist there would
be may constructs that could be allowed in the context of the property
name part of an object literal (because they would not be ambiguous) but
are not allowed in that context.

Again, we are taking about
JavaScript, so about the execution stage.

No, we are talking about the difference between constructs that result
in syntax errors and constructs that do not, so the pertinent stage is
the parsing stage.

Observe, for example, that:-

var x;
if(false){
x = {
#:1
};
}

- is still a syntax error even though the code for the object literal
cannot ever be executed.

What and how exactly C program treats the source code stream is
irrelevant here

Any C program is irrelevant (especially given that there is no need for
the parser to be a C program, and plenty of examples that are not). On
the other hand, the specification makes statements about how any
javascript implementation is supposed to behave in tokenising and
parsing in addition to execution.

yet might be interesting in other circumstances.

but if quotes are omitted, some troubles are possible on
the parsing stage so better to use them.

The only possible trouble is that if the construct created does
not conform with the syntax rules it will result in a syntax error.

You call it "the only possible trouble"? It sounds like a joke
"the worst what may happen with you - you may die"

The "trouble" here is a consequence of not knowing the syntax for the
language, and nothing else. Syntax errors are a likely consequence of
not knowing the syntax of the language you are using, and such errors
can occur in any context. Attempting to address that situation by
requiring that the property name parts of object literal always take the
form of string literals will not address the syntax errors the ignorant
author will inevitably create elsewhere.

Simple and clear.

Indeed

You are agreeing with yourself again.

As with much you write, it gets clearer as you edit more out.
There is no more talk of "syntax shortcut",

It is.

"full syntax with quotes around each
property name"

It is the full syntax because in object constructor all key
values are string literals,

No they are not.

explicitly or implicitly quoted. Again, we are taking
about JavaScript, so about the execution stage.

Despite the fact that the code for an object literal does not
necessarily ever get executed and that syntax errors happen to the
exclusion of execution?

What and how exactly C
program treats the source code stream is irrelevant here

And doubly so for implementations in Java, ML or javascript.

yet might be
interesting in other circumstances.

"the quotes will be added automatically"

See right above.

See what "right above"?

"one of reserved words in the parser list AND it changes
its own previous decision"

Right, and this is one of weak points of the current parser rules.

When you make up your own "parser rules" they do not then constitute a
weakness in £the current parser rules".

Yet I understand that the productivity impact to accommodate this
problem may be to serious to be practical.

"it
is not a constructor but a block of statements", "consider such code
as
a broken switch-case construction", etc.

Here my interpretation was wrong.

You don't say.

"False positive" because of
"default" keyword as the troublemaker. Do not forget that the
problem was obscured by say
var obj = {class: 'foobar'}
being just fine on Gecko, so it took a really unusual combination
of factors to get an object constructor, being to lazy at the
moment to type quotes and thinking that "default" as the last key
would be a good name here.

What you are saying is that not knowing the syntax rules leaves you not
knowing the syntax rules, and so wasting your time as a consequence. You
may notice how quickly it is for someone who does know the syntax rules
to spot the issue and correctly attribute it, despite their possibly
being familiar with the specification.

Yet you may order some champagne to celebrate if you wich

You mean they are processed as Identifiers if they are Identifiers?

They are not identifiers

Yes they are.

No they are not. See the preface of this post. You need to
learn to distinguish the language and the underlaying engine.

No, I only need to distinguish between Identifiers as the yare defined
in javascript and all the possible other interpretations of the term
that may be employed in other contexts. For which I need nothing more
than a precise definition of what an Identifier is in relation to
javascript, as provided by the specification.

and they are not becoming identifiers out of being processed
by this rules.

If they were not Identifiers they would not be processed as
Identifiers.

... still long way to go with you... An identifier, an expression,
an object, a function are entities distinguished by their functions
and by their usage in the *language*.

The place where these terms are used "in the *language*", as you put it,
is in the specification for the language.

Can you make an effort and to get
out from the irrelevant lower level matters?

I already have little interest in "lower level matters".

It is JavaScript forum and we are talking about JavaScript here,
not about C or C++ and how these languages are used to produce a
functional JavaScript program out of the source text.

True, but then your point would be?

The rest of post is the same delusion (or a trick?) to talk about
JavaScript running program, source code, C/C++ parser rules at
once in one sentence without any proper attribution of relevant
parts to relevant aspect.

There is a delusion here, but it is in your perception. The parsing of
the language is defined in the specification, and is relevant to the
issues here, but at no point has anything said here by anyone but you
involved "C/C++ parser rules". Javascript's parsing rules are
independent of any particular language used to implement javascript.

Ricahrd.

On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:

<snip>

The identifier foo identifies a variable foo in the context of Global
or function scope.

In a 'with' statement it identifies a property if the 'with' object has
a property with that name.

In an implicit object constructor if used in the
position of the property name it identifies
...

<snip>

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:

You need glasses. I never *started* using 'identifier' when I meant
'Identifier'.

When did source files stop containing 'programming entities' ?


<snip>

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.
snip

We've been trying to work out what you mean when you write identifier.
You seem to change your meaning every other paragraph.

John
--
John Harris

On Nov 2, 10:56*pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:

On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:

* <snip

The identifier foo identifies a variable foo in the context of Global
or function scope.

In a 'with' statement it identifies a property if the 'with' object has
a property with that name.

Let's not talk about all things at once. Right now we are looking at
an object constructor literal.

In an implicit object constructor if used in the
position of the property name it identifies

*...

* <snip

So I understand that besides the suggested definition extension above
the first definition is what you were trying to say. Well, I only can
repeat that "this is an extremely weird approach of course but at
least it has some sense within the human programming science". I still
do not understand why you are considering this approach - not used
anywhere outside this group and actually nowhere outside of this
thread - as something definitely and only right one.

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:

You need glasses. I never *started* using 'identifier' when I meant
'Identifier'.

Possibly not you, sorry then. It was a bounch of exited posts in here
with "identifier", "Identifier" mixed in all different ways.

When did source files stop containing 'programming entities' ?

at the moment it's going through the parser.

* <snip>>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.

* <snip

We've been trying to work out what you mean when you write identifier.
You seem to change your meaning every other paragraph.

That's rather stupid to claim. All the way though I was very explicit
by what does "identifier" mean in the programming (not in some "VK's
thesaurus" or so): with 3rd source definitions, with samples of
identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and
execution stage. You just need to follow the thread.

On Wed, 4 Nov 2009 at 10:27:07, in comp.lang.javascript, VK wrote:

On Nov 2, 10:56*pm, John G Harris <j... (AT) nospam (DOT) demon.co.uk> wrote:
On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:

* <snip

The identifier foo identifies a variable foo in the context of Global
or function scope.

In a 'with' statement it identifies a property if the 'with' object has
a property with that name.

Let's not talk about all things at once. Right now we are looking at
an object constructor literal.

But you're the one who is talking about identifiers naming variables. I
just added another case, where it names a property.

In an implicit object constructor if used in the
position of the property name it identifies
snip

All the way though I was very explicit
by what does "identifier" mean in the programming (not in some "VK's
thesaurus" or so): with 3rd source definitions, with samples of
identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and
execution stage. You just need to follow the thread.

In all the mainstream languages 'identifier' means any sequence of
characters in a source file that matches the collection of syntax rules
named either 'Identifier' or 'identifier'.

In database technology 'identifier' has a more specific and technical
meaning.

John
--
John Harris