allocate array element inside global object?
Geoff Cox
I'm just starting to use a global object approach but how do I create
the array element in this global object code?
myname[1] : "jane", gives an error message "missing : after property
id".
Thanks
Geoff
<script type="text/javascript">
var myObject = {
myname[1] : "jane",
alert(myname[1]);
}
</script>
Thomas 'PointedEars' Lahn
> I'm just starting to use a global object
It is _not_ a global object. It is a global variable that refers to an
Object object.
> approach but how do I create the array element in this global object
> code?
It is _not_ global object code in any sense.
> myname[1] : "jane", gives an error message "missing : after property id".
> [...]
Of course, your fantasy code is syntactically invalid.
> <script type="text/javascript">
When your example contains only script code, there is no need to wrap it
into a `script' element here.
> var myObject = { myname[1] : "jane", alert(myname[1]); }
var myObject = {
myname: [, "jane"]
};
// "jane"
window.alert(myobject.myname[1]);
RTFM.
PointedEars
Thomas 'PointedEars' Lahn
> var myObject = {
> myname: [, "jane"]
> };
>
> // "jane"
> window.alert(myobject.myname[1]);
window.alert(myObject.myname[1]);
(Sorry, apparently my Shift key was malfunctioning.)
PointedEars
Conrad Lender
> I'm just starting to use a global object approach but how do I create
> the array element in this global object code?
Terminology is important here: the term "global object" has a very
specific meaning in ECMAScript as a special built-in object, which
initially contains all the other built-in objects (like the Date and
Math objects). In browser environments, "window" usually refers to the
global object. What you mean is a "global variable", which contains
(references) an object you define yourself. That will make your object
globally available, but you shouldn't call it "global object".
> var myObject = {
> myname[1] : "jane",
> alert(myname[1]);
> }
An object literal (the part between "{" and "}" in your example) can
only contain a list of 'name: value' pairs, separated by commas. You
can't just put statements like "alert()" in there. But your code fails
even before that, because myname[1] is not a valid property name. See
Thomas's example for how this can be written without syntax errors.
- Conrad
Geoff Cox
wrote:
Thanks both,
I now see that myname[1] is not a valid property name but does this
mean I cannot use an array value inside a global variable? Maybe I'm
missing the obvious?!
Geoff
Richard Cornford
> On Thu, 25 Jun 2009 00:10:13 +0200, Conrad Lender wrote:
>> On 24/06/09 22:27, Geoff Cox wrote:
>> ... . But your code fails even before that, because myname[1]
>> is not a valid property name.
> I now see that myname[1] is not a valid property name
The character sequence "myname[1]" is a valid property name. In
javascript property names may be any sequence of zero or more characters
(any characters) (in theory, in practice there is likely to be an upper
limit to the length of property names, but that limit is likely to be
very big). What the character sequence "myname[1]" is not, is a valid
Identifier.
> but does this mean I cannot use an array value inside a
> global variable?
That depends on what you mean by "inside a global variable" and "array
value". If that question were; is it possible to use a property name
that is not a valid Identifier in an object literal then the answer
would be yes. I.E.:-
var myObject = {
"myname[1]" : "jane"
};
But there is no "array value" involved in that, and while you might use
"inside" in relation to that the things that would be "inside" are not
actually contained by the variable.
> Maybe I'm missing the obvious?!
Apparently you are missing an ability to effectively ask for
clarification when the answers you receive go over your head. (By now,
how many people have questioned you use of statements like "array value"
in this context?)
Richard.
Thomas 'PointedEars' Lahn
> Conrad Lender wrote:
>> On 24/06/09 22:27, Geoff Cox wrote:
>>> var myObject = {
>>> myname[1] : "jane",
>>> alert(myname[1]);
>>> }
>> An object literal (the part between "{" and "}" in your example) can
>> only contain a list of 'name: value' pairs, separated by commas. You
>> can't just put statements like "alert()" in there. But your code fails
>> even before that, because myname[1] is not a valid property name.
Incorret.
>> See Thomas's example for how this can be written without syntax errors.
>> [...]
>
> [...]
> I now see that myname[1] is not a valid property name
But it is. However, you cannot use `myname[1]' as it is in an Object
initializer because property names there must be either /Identifiers/ or quoted:
var myObject = {
"myname[1]": "jane"
};
That would have nothing to do with arrays; however, you could refer to that
property with
myObject["myname[1]"]
(Noticed the subtle difference? `['...`]' does not always mean an array;
preceded by an /Identifier/ or another `['...`]' it means a bracket property
accessor instead; one of the many errors in Flanagan's book which addresses
this syntax as "Array operator" -- OMG.)
> but does this mean I cannot use an array value inside a global variable?
You cannot "use an array value inside a variable", of course. You can,
however, have a variable that stores a reference to an (here: Object) object
that has a property (here: myname) that stores a reference to an Array
object. (You can also have a variable that stres a reference to an Array
object directly: `var a = [...];' or `var a = new Array(...);'.)
See my first reply; [, "jane"] denotes an Array (object) initializer where
the first element (that with index 0) is not defined so that "jane" is
the element with index 1 (fitting your property access later). Now the
value of the `myname' property is a reference to that Array object.
,-- ECMAScript Global Object --. ,-- User-defined Object object --.
| ... | | ... |
| myObject ----------------------->| myname ---------------------------.
| ... | | ... | |
`------------------------------' `--------------------------------' |
|
,-- User-defined Array object --. |
| ... | |
| 1 : string = "jane" |<-------------------------------------'
| ... |
`-------------------------------'
> Maybe I'm missing the obvious?!
Yes, you have still not RTFM, STFW, RTFFAQ, and/or you must still be relying
on a bad book or tutorial.
Don't full-quote; trim your quotes to the minimum required to retain context
(see the FAQ).
PointedEars
Geoff Cox
<Ric...@litotes.demon.co.uk> wrote:
>> Maybe I'm missing the obvious?!
>
>Apparently you are missing an ability to effectively ask for
>clarification when the answers you receive go over your head. (By now,
>how many people have questioned you use of statements like "array value"
>in this context?)
Richard,
OK!
Cheers,
Geoff
Geoff Cox
<Point...@web.de> wrote:
Thanks for the information.
My initial interest in the global variable idea was to cut down the
number of globally available variables which I was using. Since I
still have to create the array elements outside the global variable it
seems that I am back where I started? (Not entirely but almost)
What would you say is the main reason for using a global variable?
Cheers
Geoff
JR
> My initial interest in the global variable idea was to cut down the
> number of globally available variables which I was using.
You're absolutely right in cutting down the number of global
variables.
> [...] What would you say is the main reason for using a global variable?
This article has a good explanation about that:
http://www.wait-till-i.com/2006/02/16/show-love-to-the-object-literal/
> [...] Since I
> still have to create the array elements outside the global variable it
> seems that I am back where I started? (Not entirely but almost)
No, you don't have to create the array outside the global variable.
Let me show you an example:
var gPerson = {
name: {firstName: 'Jane', lastName: 'Smith'},
birthDate: '29/08/1978',
sex: 'female',
age: function () {
// Performs calculation with birthDate and the current date-time.
},
favouriteClubs: ['Arsenal', 'Chelsea', 'Manchester Utd',
'Liverpool'], // it's an array.
userID: 10123,
activeMember: true
};
Cheers,
João Rodrigues
Thomas 'PointedEars' Lahn
> No, you don't have to create the array outside the global variable.
Please stop these distributions of your misconception that
anything could be outside or inside a variable. Thanks.
PointedEars
JR
wrote:
> JR wrote:
> > No, you don't have to create the array outside the global variable.
>
> Please stop these distributions of your misconception that
> anything could be outside or inside a variable.
I didn't say that 'anything could be outside or inside a variable'?
You must be mistaken. BTW, how can a user-defined object / 'anyhing'
be outside a variable?
If you ask me how to get to the Hell, I'll be pleased to inform you if
I know a way to get there. But what you intend to do with that
information is not my problem.
Cheers,
João Rodrigues
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> JR wrote:
>>> No, you don't have to create the array outside the global variable.
>> Please stop these distributions of your misconception that
>> anything could be outside or inside a variable.
>
> I didn't say that 'anything could be outside or inside a variable'?
Yes, you did.
> You must be mistaken.
No, I'm not.
> BTW, how can a user-defined object / 'anyhing' be outside a variable?
Ask yourself. You don't seem to know what you are writing either.
OP: As explained in <news:4A434A18...@PointedEars.de>:
1. A variable defines a name for a place that can hold different values.
(1a. In ECMAScript implementations, a variable is a property of a Variable
Object. The Variable Object of the global execution context is the
Global Object.)
2. In ECMAScript implementations, such a value may be a reference to an
object.
3. An object has properties. Some are inherited from other objects,
some are not.
4. An Object object (sic!) can be created with an Object initializer.
5. You can define additional (not inherited) properties in the Object
initializer:
{
property: value,
...
}
6. A property has a value. That value may, again, be a reference to
an object, including Array objects. (It may even refer to the owning
object [tight circular reference].)
7. A "standalone" `[...]' is an Array (object) initializer. It creates
and initializes an Array object. The result of the initializer is a
reference to the created object.
8. The result of the evaluation of the Object initializer is a reference
to the created Object object.
9. With the `=' operation, that reference is assigned to the variable.
(10. The same object can be referred to by several references.)
HTH
PointedEars
JR
wrote:
> JR wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> JR wrote:
> >>> No, you don't have to create the array outside the global variable.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> >> Please stop these distributions of your misconception that
> >> anything could be outside or inside a variable.
>
> > I didn't say that 'anything could be outside or inside a variable'?
>
> Yes, you did.
You really enjoy putting words in one's mouth.
> > BTW, how can a user-defined object / 'anyhing' be outside a variable?
>
> Ask yourself. You don't seem to know what you are writing either.
I thought we were talking about a global variable. But it seems that
you've lost the focus elsewhere.
> OP: As explained in <news:4A434A18...@PointedEars.de>:
> [...] 3. An object has properties. Some are inherited from other objects,
> some are not.
>
> 4. An Object object (sic!) can be created with an Object initializer.
>
> 5. You can define additional (not inherited) properties in the Object
> initializer:
>
> {
> property: value,
> ...
> }
>
> 6. A property has a value. That value may, again, be a reference to
> an object, including Array objects. (It may even refer to the owning
> object [tight circular reference].)
>
> 7. A "standalone" `[...]' is an Array (object) initializer. It creates
> and initializes an Array object. The result of the initializer is a
> reference to the created object.
>
> 8. The result of the evaluation of the Object initializer is a reference
> to the created Object object.
>
> 9. With the `=' operation, that reference is assigned to the variable.
>
> (10. The same object can be referred to by several references.)
>
I'm not talking about object and its properties. I'm talking about
global variables creation and how to cut down the number of global
vars in a script:
function do() {
firstGlobal = { ... };
}
var secondGlobal = { ... };
window.thirdGlobal = { ... };
I prefer just one global variable instead of three:
var gLib = {
firstNotGlobalAnyMore: { ... },
secondNotGlobalAnyMore: { ... },
thirdNotGlobalAnyMore: { ... }
};
See?
João Rodrigues
JR
> window.thirdGlobal = { ... };
Please read as:
thirdGlobal = { ... };
as window.thirdGlobal is not a variable, although thirdGlobal becomes
a 'global' object. I know of the possible problems in adding objects
to window, so there's no need to comment it again, please.
João Rodrigues
kangax
> Geoff Cox wrote:
[...]
>> I now see that myname[1] is not a valid property name
>
> But it is. However, you cannot use `myname[1]' as it is in an Object
> initializer because property names there must be either /Identifiers/ or quoted:
>
> var myObject = {
> "myname[1]": "jane"
> };
>
> That would have nothing to do with arrays; however, you could refer to that
> property with
>
> myObject["myname[1]"]
>
> (Noticed the subtle difference? `['...`]' does not always mean an array;
> preceded by an /Identifier/ or another `['...`]' it means a bracket property
That is a rather odd and incomplete way of describing when brackets
denote property access (rather than array initialization).
From what I can see, there's no preceding /Identifier/, nor another
pair of brackets in the following examples, yet there is certainly
property access going on:
// preceded with reserved word
this['open'];
// preceded with FunctionExpression (part of PrimaryExpression)
(function(){})['toString'];
// preceded with NumericLiteral (part of PrimaryExpression)
(5)['valueOf'];
Isn't it precedence with /MemberExpression/ that matters here?
See ES3F 11.2.1 (Property Accessors)
[...]
--
kangax
Thomas 'PointedEars' Lahn
> Thanks for the information.
You're welcome.
> My initial interest in the global variable idea was to cut down the
> number of globally available variables which I was using.
Good idea.
The term "global variable" is correct here, although "globally available
variable" is not wrong. Just refrain from using "global object" if *the*
(ECMAScript) global object is not meant.
> Since I still have to create the array elements outside the global variable
You cannot create anything inside or outside a variable; forget about that
ill-advised notion of João. But you can create Array objects (that
encapsulate an array data structure that has elements) without another
variable. See my example.
> it seems that I am back where I started? (Not entirely but almost)
No, read my posting(s) again.
> What would you say is the main reason for using a global variable?
Do you want to know what *my* main reason is, or that of the general
population as per my observations?
My main reason currently is that then there is a globally available property
that cannot be deleted. A property that can hold arbitrary values,
including references to an object. When that is an Object object, the
global variable can provide for sort of a "namespace" that helps to avoid
(but can of course not completely avoid) possible name collisions without
the need for identifier affixes. (For example, in the local version of my
object.js I declare a global variable `jsx' (one of three, if I am not
mistaken). That variable holds a reference to an Object object. Now, each
library adds a property to that object that holds a reference to another
Object object which has properties; for example, object.js defines
jsx.object = {}, and jsx.object.isMethod = isMethod; that way if someone
would redeclare (but not overwrite) the global `isMethod',
`jsx.object.isMethod' would still work (the global declaration was retained
for backwards compatibility to previous versions of the library).
On other occasions a global variable helps that methods do not become global
in the first place; for example, Map.isInstance(), whereas `Map' is a global
variable that stores a reference to a Function object (as functions are
objects). That is pretty much the same reason as you apparently have.
However, there have been occasions when it simply did not appear to make
sense to do anything else.
As for the general population per my observations, the main reason for using
global variables is cluelessness, unfortunately. Most people don't seem to
know or understand that the same can be achieved more efficient, less
error-prone, and easier to maintain with a different approach. Example:
<news:4A3E5414...@PointedEars.de> pp.
PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> JR wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> JR wrote:
>>>>> No, you don't have to create the array outside the global variable.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> Please stop these distributions of your misconception that
>>>> anything could be outside or inside a variable.
>>> I didn't say that 'anything could be outside or inside a variable'?
>> Yes, you did.
>
> You really enjoy putting words in one's mouth.
I don't. It is instead that you don't know what you have said just minutes
ago. Maybe a sign of your getting too old for this. I have marked it
again, maybe you'll recognize it this time.
>>> BTW, how can a user-defined object / 'anyhing' be outside a variable?
>> Ask yourself. You don't seem to know what you are writing either.
>
> I thought we were talking about a global variable. But it seems that
> you've lost the focus elsewhere.
Pot, kettle, black.
> [...]
> I'm not talking about object and its properties. I'm talking about
> global variables creation and how to cut down the number of global
> vars in a script:
I know. You just don't seem to get this:
> [...]
> var gLib = {
,--------------------------------------------.
| This place is _not_ "inside the variable". |
`--------------------------------------------'
> };
PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Geoff Cox wrote:
> [...]
>>> I now see that myname[1] is not a valid property name
>> But it is. However, you cannot use `myname[1]' as it is in an Object
>> initializer because property names there must be either /Identifiers/ or quoted:
>>
>> var myObject = {
>> "myname[1]": "jane"
>> };
>>
>> That would have nothing to do with arrays; however, you could refer to that
>> property with
>>
>> myObject["myname[1]"]
>>
>> (Noticed the subtle difference? `['...`]' does not always mean an array;
>> preceded by an /Identifier/ or another `['...`]' it means a bracket property
>> accessor instead; [...]
>
> That is a rather odd and incomplete way of describing when brackets
> denote property access (rather than array initialization).
It isn't odd. For completeness, you can always read the Spec.
> From what I can see, there's no preceding /Identifier/, nor another
> pair of brackets in the following examples, yet there is certainly
> property access going on:
You are correct.
> // preceded with reserved word
> this['open'];
We have a /PrimaryExpression/ that produces a reserved word here.
> // preceded with FunctionExpression (part of PrimaryExpression)
> (function(){})['toString'];
A /FunctionExpression/ is _not_ "part of" (a) /PrimaryExpression/.
The relevant productions are:
MemberExpression ::
FunctionExpression
MemberExpression [ Expression ]
FunctionExpression ::
function Identifier_opt ( FormalParameterList_opt ) { FunctionBody }
FunctionBody ::
SourceElements
SourceElements ::
SourceElement
SourceElement ::
Statement
Statement ::
EmptyStatement
EmptyStatement ::
; [may be omitted as per section 7.9]
> // preceded with NumericLiteral (part of PrimaryExpression)
> (5)['valueOf'];
A /NumericLiteral/ is _not_ "part" of (a) /PrimaryExpression/; it can be
produced by a /Literal/ that *can be produced by* /PrimaryExpression/.
The relevant productions are:
MemberExpression ::
PrimaryExpression
PrimaryExpression ::
( Expression )
Expression ::
AssignmentExpression
AssignmentExpression ::
ConditionalExpression
ConditionalExpression ::
LogicalORExpression
LogicalORExpression ::
LogicalANDExpression
LogicalANDExpression ::
BitwiseORExpression
BitwiseORExpression ::
BitwiseXORExpression
BitwiseXORExpression ::
BitwiseANDExpression
BitwiseANDExpression ::
EqualityExpression
EqualityExpression ::
RelationalExpression
RelationalExpression ::
ShiftExpression
ShiftExpression ::
AdditiveExpression
AdditiveExpression ::
MultiplicativeExpression
MultiplicativeExpression ::
UnaryExpression
UnaryExpression ::
PostfixExpression
PostfixExpression ::
LeftHandSideExpression
LeftHandSideExpression ::
NewExpression
NewExpression ::
MemberExpression
MemberExpression ::
PrimaryExpression
PrimaryExpression ::
Literal
Literal ::
NumericLiteral
NumericLiteral ::
DecimalLiteral
DecimalLiteral ::
DecimalIntegerLiteral ExponentPart_opt
DecimalIntegerLiteral ::
NonZeroDigit DecimalDigits_opt
NonZeroDigit :: one of
1 2 3 4 5 6 7 8 9
> Isn't it precedence with /MemberExpression/ that matters here?
"Precedence with"? Generally, probably you mean the right thing.
In this example, certainly not (whatever that means).
PointedEars
JR
wrote:
> > You really enjoy putting words in one's mouth.
>
> I don't. It is instead that you don't know what you have said just minutes
> ago. Maybe a sign of your getting too old for this. I have marked it
> again, maybe you'll recognize it this time.
No I am not. But it's you that has become 'mental' in this ng. Get
some fresh air, talk to your friends around you, if there's any :-)
> > I thought we were talking about a global variable. But it seems that
> > you've lost the focus elsewhere.
>
> Pot, kettle, black.
You're watching too much TV. Blue Peter, Teletubbies maybe?
> > [...]
> > I'm not talking about object and its properties. I'm talking about
> > global variables creation and how to cut down the number of global
> > vars in a script:
>
> I know. You just don't seem to get this:
>
> > [...]
> > var gLib = {
>
> ,--------------------------------------------.
> | This place is _not_ "inside the variable". |
> `--------------------------------------------'
What 'place' is that? How can a 'place' be inside the variable?
As you don't seem to understand, I can draw for you If you wish ;-)
Cheers,
João
kangax
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> (Noticed the subtle difference? `['...`]' does not always mean an array;
>>> preceded by an /Identifier/ or another `['...`]' it means a bracket property
>>> accessor instead; [...]
>> That is a rather odd and incomplete way of describing when brackets
>> denote property access (rather than array initialization).
>
> It isn't odd. For completeness, you can always read the Spec.
>
>> From what I can see, there's no preceding /Identifier/, nor another
>> pair of brackets in the following examples, yet there is certainly
>> property access going on:
>
> You are correct.
>
>> // preceded with reserved word
>> this['open'];
>
> We have a /PrimaryExpression/ that produces a reserved word here.
Yes.
>
>> // preceded with FunctionExpression (part of PrimaryExpression)
>> (function(){})['toString'];
>
> A /FunctionExpression/ is _not_ "part of" (a) /PrimaryExpression/.
I think you are mistaken.
The Grouping Operator - `PrimaryExpression: ( Expression )` - evaluates
/Expression/ (/FunctonExpression/ in this case) and produces
/PrimaryExpression/
PrimaryExpression :
this
Identifier
Literal
ArrayLiteral
ObjectLiteral
( Expression )
This /PrimaryExpression/ in its turn constitutes /MemberExpression/:
MemberExpression :
PrimaryExpression
FunctionExpression
MemberExpression [ Expression ]
MemberExpression . Identifier
new MemberExpression Arguments
- which produces property accessor. How is /FunctionExpression/ not part
of /PrimaryExpression/ in `(function(){})`?
Or are you correcting terminology I'm using?
[...]
>
>> // preceded with NumericLiteral (part of PrimaryExpression)
>> (5)['valueOf'];
>
> A /NumericLiteral/ is _not_ "part" of (a) /PrimaryExpression/; it can be
> produced by a /Literal/ that *can be produced by* /PrimaryExpression/.
I find those - "part of" and "produced by" - to have identical meaning
in this context.
"When Date is called as *part of* a new expression, it is a
constructor: it initialises the newly created object."
-- ES3F, 15.9.3
What am I missing?
Thanks for a breakdown.
>
>> Isn't it precedence with /MemberExpression/ that matters here?
>
> "Precedence with"? Generally, probably you mean the right thing.
> In this example, certainly not (whatever that means).
Poor wording on my part. I should have said "preceded by", as in your
sentence - "... preceded by an /MemberExpression/ it means a bracket
property accessor instead ..."
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> JR wrote:
>> ,--------------------------------------------.
>> | This place is _not_ "inside the variable". |
>> `--------------------------------------------'
>
> What 'place' is that? How can a 'place' be inside the variable?
Yes, one wonders. Yet you keep on saying that something could be inside or
outside a (global) variable, like in
,-<news:37b4dd15-2928-4738...@j19g2000vbp.googlegroups.com>
| No, you don't have to create the array outside the global variable.
So much for "going 'mental'".
PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>> // preceded with FunctionExpression (part of PrimaryExpression)
>>> (function(){})['toString'];
>> A /FunctionExpression/ is _not_ "part of" (a) /PrimaryExpression/.
>
> I think you are mistaken.
I think you are. Evidence has been provided. Where's yours?
> The Grouping Operator - `PrimaryExpression: ( Expression )` - evaluates
> /Expression/ (/FunctonExpression/ in this case) and produces
> /PrimaryExpression/
Gibberish, not evidence.
> [grammar]
Hello? I have already quoted the relevant parts, so you can assume I am
very well aware of them.
> - which produces property accessor. How is /FunctionExpression/ not part
> of /PrimaryExpression/ in `(function(){})`?
It simply isn't.
> Or are you correcting terminology I'm using?
Both.
>>> // preceded with NumericLiteral (part of PrimaryExpression)
>>> (5)['valueOf'];
>> A /NumericLiteral/ is _not_ "part" of (a) /PrimaryExpression/; it can be
>> produced by a /Literal/ that *can be produced by* /PrimaryExpression/.
>
> I find those - "part of" and "produced by" - to have identical meaning
> in this context.
They don't.
> "When Date is called as *part of* a new expression, it is a
> constructor: it initialises the newly created object."
That is an entirely different thing; it means
new Date
> What am I missing?
One is a production in the ECMAScript grammar; the other one is not.
PointedEars
Conrad Lender
> Geoff Cox wrote:
>> On Thu, 25 Jun 2009 00:10:13 +0200, Conrad Lender wrote:
>>> On 24/06/09 22:27, Geoff Cox wrote:
> <snip>
>>> ... . But your code fails even before that, because myname[1]
>>> is not a valid property name.
> <snip>
>> I now see that myname[1] is not a valid property name
>
> The character sequence "myname[1]" is a valid property name.
> var myObject = {
> "myname[1]" : "jane"
> };
JFTR: I'm aware of this, but a property name with square brackets is not
what the OP wanted; he wanted an array. I had actually written
"identifier" at first, but then I thought that a simpler formulation
would be more helpful for his understanding, and changed it to "property
name". I should have known that this would lead to several corrections,
and should have sacrificed readability for exact terms.
Another thing which just occurred to me: it could be that what Geoff
meant by "inside/outside the variable" was the need to add arrays (or
array elements) outside of the object literal. If that's the case, maybe
this example will help:
var myObj = {
str1: "string one",
str2: "string two"
};
// (... some other, unrelated code ...)
// then we add an array to myObj:
myObj.myTodoList = ["item one", "item two"];
// add a new array element:
myObj.myTodoList.push("item three");
// read the second element:
var item = myObj.myTodoList[1];
- Conrad
kangax
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> kangax wrote:
>>>> // preceded with FunctionExpression (part of PrimaryExpression)
>>>> (function(){})['toString'];
>>> A /FunctionExpression/ is _not_ "part of" (a) /PrimaryExpression/.
>> I think you are mistaken.
>
> I think you are. Evidence has been provided. Where's yours?
Look again at your first breakdown and try to find what's missing there.
>
>> The Grouping Operator - `PrimaryExpression: ( Expression )` - evaluates
>> /Expression/ (/FunctonExpression/ in this case) and produces
>> /PrimaryExpression/
>
> Gibberish, not evidence.
You just snipped evidence below.
>
>> [grammar]
>
> Hello? I have already quoted the relevant parts, so you can assume I am
> very well aware of them.
Being "very well aware" of something does not exclude a possibility of
an oversight.
[...]
--
kangax
Richard Cornford
> On 25/06/09 11:05, Richard Cornford wrote:
>> Geoff Cox wrote:
>>> On Thu, 25 Jun 2009 00:10:13 +0200, Conrad Lender wrote:
>>>> On 24/06/09 22:27, Geoff Cox wrote:
>> <snip>
>>>> ... . But your code fails even before that, because myname[1]
>>>> is not a valid property name.
>> <snip>
>>> I now see that myname[1] is not a valid property name
>>
>> The character sequence "myname[1]" is a valid property name.
> [...]
>> var myObject = {
>> "myname[1]" : "jane"
>> };
>
> JFTR: I'm aware of this, but a property name with square
> brackets is not what the OP wanted; he wanted an array.
No he doesn't. In the event that all the misdirecting talk of arrays
ever gets sorted out here I suspect that the only array actually
involved will turn out to be a PHP array, so only indirectly involved
and existing in a different environment running on a different machine
(not necessarily the latter is development/testing).
> I had actually written "identifier" at first, but then I thought
> that a simpler formulation would be more helpful for his
> understanding, and changed it to "property name". I should have
> known that this would lead to several corrections,
> and should have sacrificed readability for exact terms.
Terminology is always a pain. It is difficult to decide where to pitch
it; too loose and the result is meaningless (often misleading (as in 90%
of the uses of the term '"scope")) drivel and too strict and the result
may become (literally) esoteric.
While it is useful that ECMA 262 (3rd Ed.) provides an external,
objective set of terminology and its definitions, I can see ES4 muddying
the water a little as concepts like the "Variable object" vanish from
the new terminology. It will be interesting to see how that gets handled
during the transition period when ES3 and ES4 implementations operate
side by side. Then, will it be 'strict' to use the ES4 terminology and
algorithms in explaining things that will have the same outcomes as
would be explained by the ES3 equivalents?
> Another thing which just occurred to me: it could be that
> what Geoff meant by "inside/outside the variable"
I don't expect to here Geoff explaining what he meant, despite his being
the only person who knows for sure.
> was the need to add arrays (or array elements) outside of
> the object literal. If that's the case, maybe this example
> will help:
>
> var myObj = {
> str1: "string one",
> str2: "string two"
> };
>
> // (... some other, unrelated code ...)
>
> // then we add an array to myObj:
> myObj.myTodoList = ["item one", "item two"];
<snip>
But that doesn't deny the opportunity to create the object as:-
var myObj = {
str1: "string one",
str2: "string two",
myTodoList:["item one", "item two"]
};
Richard.
Geoff Cox
>Jo�o Rodrigues
Thanks Jo�o - that's useful for me.
Cheers,
Geoff
Conrad Lender
> Conrad Lender wrote:
>> JFTR: I'm aware of this, but a property name with square
>> brackets is not what the OP wanted; he wanted an array.
>
> No he doesn't. In the event that all the misdirecting talk of arrays
> ever gets sorted out here I suspect that the only array actually
> involved will turn out to be a PHP array, so only indirectly involved
> and existing in a different environment running on a different machine
> (not necessarily the latter is development/testing).
Ok, I guess that's possible. He was asking about arrays, I tried to
provide an answer.
> While it is useful that ECMA 262 (3rd Ed.) provides an external,
> objective set of terminology and its definitions, I can see ES4 muddying
> the water a little as concepts like the "Variable object" vanish from
> the new terminology.
I assume you mean ES5. I have to admit that I haven't really made an
effort to learn the details of ES5 yet; it's still a draft, after all,
and there are very few implementations to experiment with. I've read
about the most important changes, but I haven't read the draft itself.
The concept of a "variable object" was used in ES3 as a means to define
the behavior of an implementation (meaning that it isn't actually
required to create such an object, only that ist has to act as if it
did). Since ES5 is supposed to be downward compatible with ES3, I
suppose the underlying logic hasn't changed, which only leaves the term
"variable object", which you say is missing from the ES5 specs. I've
never been very happy with that name (although I accept that the concept
is necessary), because it makes ES even harder to explain than it
already is. This isn't something that should ever show up in a tutorial,
or even in a reference, it's just an implementation detail - all it does
is lead some people (in this group) to write things like "No, it's not a
local variable, you idiot, it's a property of the execution context's
variable object / activation object". This is completely and utterly
incomprehensible to anybody without an intimate knowledge of the
ECMAScript specifications. If ES5 managed to come up with more intuitive
terms, I'm all for it.
>> var myObj = {
>> str1: "string one",
>> str2: "string two"
>> };
>>
>> // (... some other, unrelated code ...)
>>
>> // then we add an array to myObj:
>> myObj.myTodoList = ["item one", "item two"];
> <snip>
>
> But that doesn't deny the opportunity to create the object as:-
>
> var myObj = {
> str1: "string one",
> str2: "string two",
> myTodoList:["item one", "item two"]
> };
No, it doesn't. I only wanted to illustrate what creating an array
"outside the variable" could look like.
- Conrad
Richard Cornford
> On 25/06/09 19:29, Richard Cornford wrote:
>> While it is useful that ECMA 262 (3rd Ed.) provides an
>> external, objective set of terminology and its definitions,
>> I can see ES4 muddying the water a little as concepts like
>> the "Variable object" vanish from the new terminology.
>
> I assume you mean ES5.
Yes I did. I was thinking 5 but apparently wrote 4.
> I have to admit that I haven't really made an effort to
> learn the details of ES5 yet; it's still a draft, after all,
It is a draft, but not for much longer.
> and there are very few implementations to experiment with.
> I've read about the most important changes, but I haven't
> read the draft itself. The concept of a "variable object"
> was used in ES3 as a means to define the behavior of an
> implementation (meaning that it isn't actually required
> to create such an object, only that ist has to act as if it
> did). Since ES5 is supposed to be downward compatible with ES3,
> I suppose the underlying logic hasn't changed, which only
> leaves the term "variable object",
No, there is now more going on to accommodate constants. The new
behaviour spec accommodates the old, but is more elaborate.
> which you say is missing from the ES5 specs.
The "Variable object" is a victim of the change.
> I've never been very happy with that name (although I accept
> that the concept is necessary), because it makes ES even
> harder to explain than it already is.
I have always thought that the obscure bit was having an "Activation
object" for functions that then becomes the "Variable object".
> This isn't something that should ever show up in a tutorial,
> or even in a reference, it's just an implementation detail -
Haven't you just said that the "Variable object" does not have to exist
in an implementation at all (which is the case)?
Javascript is a language that is defined in terms of the expected
behaviour; it is required to behave as if ... . That makes understanding
the "as if .. " very valuable in understanding the language. The
"variable objects", their creation, named properties, location (on scope
chains) and lifespan are all very important in understanding, for
example, closures in javascript. I am yet to see an attempt to explained
closures in javascript that was complete enough to render the behaviour
predictable without discussing "Variable objects".
> all it does is lead some people (in this group) to write
> things like "No, it's not a local variable, you idiot, it's
> a property of the execution context's
> variable object / activation object".
When that is the case there is no good reason for not saying so. Of
course you have to expect people to start out not being able to perceive
the (very subtitle and not too significant) difference, so giving them a
hard time for being what they are most likely to be is not reasonable.
It is also well worth realising that useful communication is a two way
process and making some concessions (in terminology, for example) helps
things move forward.
> This is completely and utterly incomprehensible to anybody
> without an intimate knowledge of the ECMAScript specifications.
Not completely, and realising that you are not comprehending the
language used to discuss javascript could be taken as an indication of
the direction future study should take. The bottom line is that nobody
will gain a good understanding of the language without some familiarity
with the spec, so where a good understanding is the aim starting sooner
means arriving sooner.
It is also possible for people who do not understand the response they
receive to ask for clarification. Sometimes the responses to such
requests turn out to be very good explanations of the subject.
> If ES5 managed to come up with more intuitive
> terms, I'm all for it.
No, the new spec is much the same. There were plans to have the spec
written in ML (the abandoned ES 4 spec at least) which would have made
the whole thing much more precise, and hugely esoteric.
<snip>
> No, it doesn't. I only wanted to illustrate what creating
> an array "outside the variable" could look like.
Eventually you will tire of having ti guess what people are whitening on
about, and probably will then start insisting that they spell it out
;-)
Richard.
Conrad Lender
> Conrad Lender wrote:
>> This isn't something that should ever show up in a tutorial,
>> or even in a reference, it's just an implementation detail -
>
> Haven't you just said that the "Variable object" does not have to exist
> in an implementation at all (which is the case)?
What I meant was that ECMA-262/3 is a technical specification, aimed at
those who want to create an implementation themselves. I'm not sure that
terms like "activation object" or "variable object" should have a place
in a (hypothetical) reference aimed at *users* of the language.
> The "variable objects", their creation, named properties, location (on
> scope chains) and lifespan are all very important in understanding, for
> example, closures in javascript. I am yet to see an attempt to explained
> closures in javascript that was complete enough to render the behaviour
> predictable without discussing "Variable objects".
Yes, closures are difficult. Off the top of my head, I can't think of a
way to explain them without mentioning some object which can maintain
the state of variables/arguments/functions in a scope (execution
context) between calls to a closure.
But still... there has to be a better way to explain all this than the
ES specs. They serve their purpose, of course, and they can give a
greater understanding about how this language actually works - and now
we've become so used to them that we don't find it strange to read an
implementor's reference just to see how Date.parse is supposed to work.
We talk to each other about [[Class]] and [[Get]] and [[Construct]], and
activation objects and variable objects, but I don't think these terms
were ever intended for people who *use* ES to get a job done. Of course,
the whole thing is only made worse by the lack of good reference books.
> It is also well worth realising that useful communication is a two way
> process and making some concessions (in terminology, for example) helps
> things move forward.
Point taken, I'll be more careful in my explanations in the future :-)
>> This is completely and utterly incomprehensible to anybody
>> without an intimate knowledge of the ECMAScript specifications.
...
> It is also possible for people who do not understand the response they
> receive to ask for clarification. Sometimes the responses to such
> requests turn out to be very good explanations of the subject.
Yes. Unfortunately, they more often turn out to be "RTFM, STFW". But I
have to admit that lurking in this group made me realize that I
absolutely needed to know the specs before I could take part in any
meaningful discussion here. So, it worked for me. But I can still
remember the time when I had my first contact with JavaScript, some 12
years ago. At that time, I would never have dreamed I'd ever be doing
this sort of thing professionally. All I saw was HTML and JS source
code, which were readily visible on any web page and just screamed "try
me out and modify me". I figure a lot of people are still making this
same discovery today, and if they find their way to this group, I think
they should be welcomed and supported, instead of being ridiculed for
not knowing what an activation object is.
- Conrad
Richard Cornford
> On 26/06/09 01:13, Richard Cornford wrote:
>> Conrad Lender wrote:
> [variable object]
>>> This isn't something that should ever show up in a tutorial,
>>> or even in a reference, it's just an implementation detail -
>>
>> Haven't you just said that the "Variable object" does not have
>> to exist in an implementation at all (which is the case)?
>
> What I meant was that ECMA-262/3 is a technical specification,
> aimed at those who want to create an implementation themselves.
And those who want to understand how the results of the implementation's
efforts are supposed to behave.
> I'm not sure that terms like "activation object" or "variable
> object" should have a place in a (hypothetical) reference
> aimed at *users* of the language.
The concepts that those terms describe exist in the language whatever
name they are given. People do employ alternative terminology for them,
for example Flanagan uses "calling object" in place of "activation
object". The problem with that particular one is that if a function has
a 'caller' exposed by the implementation that object is not the
"Activation object", and it is not uncommon for people to refer to the
object providing he - this - value as the 'calling object'. It is also
surprisingly common for people to refer to the - this - value as the
"scope". A proliferation of terminology is a bad thing, it implies a
need for everyone to define the terms they are using each time they are
used in order to avoid ambiguity and misconception.
The advantage in using the terminology form the specification is that it
has fairly well defined and fixed meaning. Everyone can speak the same
language with little risk of being ambiguous or misunderstood.
>> The "variable objects", their creation, named properties, location
>> (on scope chains) and lifespan are all very important in
>> understanding, for example, closures in javascript. I am yet
>> to see an attempt to explained closures in javascript that
>> was complete enough to render the behaviour predictable without
>> discussing "Variable objects".
>
> Yes, closures are difficult. Off the top of my head, I can't
> think of a way to explain them without mentioning some object
> which can maintain the state of variables/arguments/functions
> in a scope (execution context) between calls to a closure.
So not using the terminology from the outset means that someone with
their own mental model and associated terminology is likely come to a
point when they have to totally re-organise their perceptions in order
to get past the hurdle of understanding closures.
> But still... there has to be a better way to explain all this
> than the ES specs.
If the spec defines the behaviour then must also explain the behaviour.
> They serve their purpose, of course, and they can give a
> greater understanding about how this language actually works -
> and now we've become so used to them that we don't find it
> strange to read an implementor's reference just to see how
> Date.parse is supposed to work. We talk to each other about
> [[Class]] and [[Get]] and [[Construct]], and activation objects
> and variable objects, but I don't think these terms were ever
> intended for people who *use* ES to get a job done. Of course,
> the whole thing is only made worse by the lack of good reference
> books.
>
>> It is also well worth realising that useful communication is a
>> two way process and making some concessions (in terminology,
>> for example) helps things move forward.
>
> Point taken, I'll be more careful in my explanations in the future :-)
>
>>> This is completely and utterly incomprehensible to anybody
>>> without an intimate knowledge of the ECMAScript specifications.
> ...
>> It is also possible for people who do not understand the response
>> they receive to ask for clarification. Sometimes the responses
>> to such requests turn out to be very good explanations of the
>> subject.
>
> Yes. Unfortunately, they more often turn out to be "RTFM, STFW".
That depends quite a lot on who is providing the response. Of course it
takes time to write out (and plan) an extensive explanatory response so
the number that can be made available is limited, but still the archives
are full of them and there will be more.
> But I have to admit that lurking in this group made me realize
> that I absolutely needed to know the specs before I could take
> part in any meaningful discussion here.
It might be argued that you should have said 'any meaningful discussion'
(about javascript) full stop.
> So, it worked for me. But I can still remember the time when
> I had my first contact with JavaScript, some 12 years ago. At
> that time, I would never have dreamed I'd ever be doing this
> sort of thing professionally. All I saw was HTML and JS source
> code, which were readily visible on any web page and just screamed
> "try me out and modify me". I figure a lot of people are still
> making this same discovery today, and if they find their way to
> this group, I think they should be welcomed and supported, instead
> of being ridiculed for not knowing what an activation object is.
Who is ridiculing people for not knowing what an "Activation object" is?
Expecting people to start out knowing things unrealistic and
unreasonable. On the other hand, having been made aware of "Activation
objects" negating to do something about finding out what they are could
be taken as an indicator of an individual who is not worth anyone's
effort.
Richard.