FAQ Topic - How do I access a property of an object using a string?

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How do I access a property of an object using a string?
-----------------------------------------------------------------------

There are two equivalent ways to access properties: the dot
notation and the square bracket notation. What you are looking
for is the square bracket notation in which the dot, and the
identifier to its right, are replaced with a set of square
brackets containing a string. The value of the string matches
the identifier. For example:-

//dot notation
var bodyElement = document.body;

//square bracket notation, using an expression
var bodyElement = document["bo"+"dy"];

http://www.jibbering.com/faq/faq_notes/square_brackets.html


===
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://www.jibbering.com/faq/.
The FAQ workers are a group of volunteers.

 

[Peter Michaux]

Is the word "equivalent" correct here? It seems like square bracket
notation is more powerful in general.

 

[Randy Webb]

Peter Michaux said the following on 11/17/2006 7:37 PM:

Is the word "equivalent" correct here?

No, it is not correct.

It seems like square bracket notation is more powerful in general.

It is, but, not for the reasons most people think.

 

[Peter Michaux]

Peter Michaux said the following on 11/17/2006 7:37 PM:

It is, but, not for the reasons most people think.

What do most people think? What are the real reasons?

 

[Randy Webb]

Peter Michaux said the following on 11/17/2006 8:28 PM:

What do most people think?

From my personal experience, when the issue gets discussed it is always
brought up about being "ECMA compatible" or more "cross browser
compatible". When it was last talked about, I asked for a browser that
would take bracket notation and not dot notation (with the exception
that is noted in the FAQ) and nobody - to date - has come up with one
where document.forms['myForm'].elements['myInput'].value will work when
document.myForm.myInput.value won't.

What are the real reasons?

The reason bracket notation is more powerful than dot notation? One very
easy example:

PHP generated forms with names of "myElement[]". PHP creates an array of
them on the server. You can't access that element with Dot Notation in JS.

There is nowhere that dot notation will work that bracket notation
won't. There are times though that dot notation won't work but bracket
notation will. That alone makes it more powerful.

The counter argument is that dot notation is faster - and it is.

 

[Richard Cornford]

Is the word "equivalent" correct here? It seems like square
bracket notation is more powerful in general.

Bracket notation is often erroneously perceived as a special syntax for
accessing Array objects (it is even asserted as being such numerous poor
javascript books and web 'resources'). This leads to situations where
people create Array objects and then dynamically add exclusively
non-array index properties to those arrays (employing the object-ness of
the Array and not its Array-ness).

Dot notation and bracket notation are both property accessors, they both
employ precisely the same algorithm (once the expression in the brackets
of a bracket notation property accessor has been evaluated and
type-converted to a string (if necessary)) to do precisely the same job
(reference the properties of objects). In that sense they are
equivalent.

The only sense in which bracket notation is "more powerful" is that it
has no restrictions on the character sequence used as a property name,
while dot notation can only be constructed from Identifiers and so the
syntax rules for Identifiers apples to the character sequences of the
property names that may be accessed with dot notation. This leaves
bracket nation more widely applicable (as, for example, the only option
when referencing the 'array index' properties of an Array) and more
flexible as the value of expression used in the brackets is determined
at run-time rather than when the code is written.

So: All dot notation property accessors may be substituted with bracket
notation property accessors and the only things that make the reverse
not possible are that not all string values could qualify as valid
Identifiers and that the string values used for the property names are
determined at runtime in a bracket notation property accessor.

It is better for the FAQ to stress the often under appreciated
equivalence of the two types of object property accessors and leave it
to readers of the referenced article to understand the wider
possibilities that bracket notation introduces.

Richard.

 

[John G Harris]

The only sense in which bracket notation is "more powerful" is that it
has no restrictions on the character sequence used as a property name,
while dot notation can only be constructed from Identifiers and so the
syntax rules for Identifiers apples to the character sequences of the
property names that may be accessed with dot notation. This leaves
bracket nation more widely applicable (as, for example, the only option
when referencing the 'array index' properties of an Array) and more
flexible as the value of expression used in the brackets is determined
at run-time rather than when the code is written.

<snip>

You've given us the right description there. Bracket notation is "more
widely applicable" and "more flexible".

"More powerful" is misleading or meaningless, or both. For instance,
it's easier to spot a typing error in a.l than in a.["l"], so dot
notation is sometimes more "powerful".

John

 

[Dr J R Stockton]

There are two equivalent ways to access properties: the dot notation
and the square bracket notation. What you are looking for is the square
bracket notation in which the dot, and the identifier to its right, are
replaced with a set of square brackets containing a string. The value
of the string matches the identifier. For example:-

//dot notation
var bodyElement = document.body;

//square bracket notation, using an expression
var bodyElement = document["bo"+"dy"];

http://www.jibbering.com/faq/faq_notes/square_brackets.html

Properties can be addressed by dot notation and by square bracket
notation.

Dot notation is appropriate where the "term" is known at programming
time.

Square bracket notation is necessary if the "term" must be supplied at
run time.

For example:-

// dot notation
var bodyElement = document.body;

// square bracket notation, using a computed variable
var MyStringVal = "bo"+"dy"
var bodyElement = document[MyStringVal];

http://www.jibbering.com/faq/faq_notes/square_brackets.html

-

IMHO, that wording allows for cases, if any exist, where "term" is known
at programming time but bracket notation is necessary.

In the case of exec(control.value) programming time is nested in
run time.

-

So why did someone respected here advise me to use the first of these
without mentioning the second?

document.forms["F"].X0.value
document.forms.F.X0.value

 

[Randy Webb]

Dr J R Stockton said the following on 11/18/2006 3:44 PM:

Square bracket notation is necessary if the "term" must be supplied at
run time.

That is not always true. Square bracket notation is necessary if the
"term" has characters in that JS doesn't like. PHP's array-ness of
inputs comes to mind first. If the name of the inputs is "myInput[]"
then you have to use bracket notation to access it using it's name but
the "term" will be known at programming time.

That very specific issue is dealt with in Section 4.25.

 

[Dr J R Stockton]

Dr J R Stockton said the following on 11/18/2006 3:44 PM:

Square bracket notation is necessary if the "term" must be supplied at
run time.

That is not always true. Square bracket notation is necessary if the
"term" has characters in that JS doesn't like. PHP's array-ness of
inputs comes to mind first. If the name of the inputs is "myInput[]"
then you have to use bracket notation to access it using it's name but
the "term" will be known at programming time.

That very specific issue is dealt with in Section 4.25.

When I wrote 'Square bracket notation is necessary if the "term" must be
supplied at run time', I meant 'Square bracket notation is necessary if
the "term" must be supplied at run time'.

If I had meant 'Square bracket notation is necessary if and only if the
"term" must be supplied at run time', I would have written 'Square
bracket notation is necessary if and only if the "term" must be supplied
at run time'.

The example you refer to is covered by the explanatory wording further
down : 'IMHO, that wording allows for cases, if any exist, where "term"
is known at programming time but bracket notation is necessary.'.

One could add, to the bit you quoted above, 'or if the "term" has
characters in that JS doesn't like' and any further cases; but one must
avoid the appearance of giving a complete list if the list is not
necessarily complete.

IMHO, the cases I gave are sufficient for the FAQ, though more might be
added in Notes.



AISB, ISTM that in the USA "Logic 101" states that "A implies B" implies
"B implies A". In fact, "A implies B" implies "not B implies not A".


FAQ 4.25 is OK; it says that illegal characters require bracket
notation, and does not say that bracket notation is only required for
illegal characters.


<FAQENTRY>
The first, index section of the FAQ misuses <H4> & <H5> - and, when
viewed without CSS, <H5> is by default rather small. It would be better
done with nested <ul>, perhaps all in a <div> that makes it Bold.

It's a good idea to read the newsgroup and its old FAQ. See below.

 

[John G Harris]

There are two equivalent ways to access properties: the dot notation
and the square bracket notation. What you are looking for is the square
bracket notation in which the dot, and the identifier to its right, are
replaced with a set of square brackets containing a string. The value
of the string matches the identifier. For example:-

//dot notation
var bodyElement = document.body;

//square bracket notation, using an expression
var bodyElement = document["bo"+"dy"];

http://www.jibbering.com/faq/faq_notes/square_brackets.html

Properties can be addressed by dot notation and by square bracket
notation.

Dot notation is appropriate where the "term" is known at programming
time.

Dot notation is not appropriate when the property name does not obey the
rules for identifiers.

Square bracket notation is necessary if the "term" must be supplied at
run time.

"term" is pretty woolly. What's wrong with property name? It's explicit
and accurate.

John

 

[John G Harris]

PHP's array-ness of inputs comes to mind first. If the name of the
inputs is "myInput[]" then you have to use bracket notation to access
it using it's name but the "term" will be known at programming time.

<snip>

What is it about PHP that forces it to dictate javascript property
names?

John

 

[Matt Kruse]

What is it about PHP that forces it to dictate javascript property
names?

Programmer convenience - if you name an array of checkboxes "input[]" for
example, then they will be automagically converted to an array on the server
side. And the input name is a property or the form.elements[] collection
which is accessed via javascript.

 

[Randy Webb]

John G Harris said the following on 11/19/2006 3:13 PM:

PHP's array-ness of inputs comes to mind first. If the name of the
inputs is "myInput[]" then you have to use bracket notation to access
it using it's name but the "term" will be known at programming time.

<snip>

What is it about PHP that forces it to dictate javascript property
names?

When form elements are submitted to PHP on the server, any like names
followed by [] are automatically put into a PHP array. As a result, you
see NAME attributes that look like this: 'myInput[]'. It has nothing to
do with dictating javascript property names, it has to do with having to
use bracket notation to access that form element when it is named like that.

 

[Randy Webb]

Dr J R Stockton said the following on 11/19/2006 1:22 PM:

Dr J R Stockton said the following on 11/18/2006 3:44 PM:

Square bracket notation is necessary if the "term" must be supplied at
run time.

That is not always true. Square bracket notation is necessary if the
"term" has characters in that JS doesn't like. PHP's array-ness of
inputs comes to mind first. If the name of the inputs is "myInput[]"
then you have to use bracket notation to access it using it's name but
the "term" will be known at programming time.

That very specific issue is dealt with in Section 4.25.

When I wrote 'Square bracket notation is necessary if the "term" must be
supplied at run time', I meant 'Square bracket notation is necessary if
the "term" must be supplied at run time'.

And my point is that your statement is false. It implies that is the
only time it is necessary and that isn't true. Perhaps if I had quoted
the previous line to the one I quoted you wouldn't be splitting hairs
about what I wrote. Because the previous line is also patently false.

 

[Dr J R Stockton]

In comp.lang.javascript message

Dot notation is not appropriate when the property name does not obey the
rules for identifiers.

Then :
"Dot notation is appropriate where the "term" is an identifier known at
programming time."

"term" is pretty woolly. What's wrong with property name? It's explicit
and accurate.

I put it in quotes because something better failed to occur to me at the
time! Though, in the context, "property" might be considered implicit.



To allow for the Merkins, the FAQ should contain, in Section 1, the
observation that "if" does not mean "if and only if"; and the "if"s in
the more rigorous parts of the FAQ should be scrutinised for compliance.

In 4.7, for example, "if" is correct; the condition is sufficient but
not necessary (example : for integer N, (N - N/2 - N/2) is exactly zero,
though if N is 1 then N/2 is non-integer).

But in 4.31 the second "if" should be "whether".

<FAQENTRY>
4.4, 4.10 Subject : if -> whether

S.1 para 4 : false.

S.1 para 7 : We use those conventions. "Suggestions" is undefined. If
the browser supports CSS, then by default one will see ...

In 4.31 the second "if" should be "whether".

 

[Randy Webb]

Dr J R Stockton said the following on 11/20/2006 11:50 AM:

To allow for the Merkins, the FAQ should contain, in Section 1, the
observation that "if" does not mean "if and only if"; and the "if"s in
the more rigorous parts of the FAQ should be scrutinised for compliance.

And to allow for the anally retentive people among us Section 1 should
contain a note about being anally retentive!

 

[John G Harris]

What is it about PHP that forces it to dictate javascript property
names?

Programmer convenience - if you name an array of checkboxes "input[]" for
example, then they will be automagically converted to an array on the server
side. And the input name is a property or the form.elements[] collection
which is accessed via javascript.

Thank you.

This looks suspiciously like eval to me

John

PS See! It isn't only VK who gets thanked.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

Dr J R Stockton said the following on 11/19/2006 1:22 PM:

Dr J R Stockton said the following on 11/18/2006 3:44 PM:

<snip>

Square bracket notation is necessary if the "term" must be supplied at
run time.

That is not always true. Square bracket notation is necessary if the
"term" has characters in that JS doesn't like. PHP's array-ness of
inputs comes to mind first. If the name of the inputs is "myInput[]"
then you have to use bracket notation to access it using it's name
but the "term" will be known at programming time.

That very specific issue is dealt with in Section 4.25.

When I wrote 'Square bracket notation is necessary if the "term"
must be supplied at run time', I meant 'Square bracket notation is
necessary if the "term" must be supplied at run time'.

And my point is that your statement is false. It implies that is the
only time it is necessary and that isn't true. Perhaps if I had quoted
the previous line to the one I quoted you wouldn't be splitting hairs
about what I wrote. Because the previous line is also patently false.

No : the problem is that not only can you not write English, but also
you cannot even read it.

The word "if" does not mean "if and only if".

My statement quoted at the top is equivalent to

If the "term" must be supplied at run time, then square bracket
notation is necessary.

But, of course, "then" does not mean "then and only then".

Consider "If a person lives in Utah, then he/she is resident in
America.". That's generally believed to be true, even I presume in
Iowa, where dwellers are also American residents.

 

[Randy Webb]

Dr J R Stockton said the following on 11/20/2006 3:50 PM:

In comp.lang.javascript message <[email protected]>,

Dr J R Stockton said the following on 11/19/2006 1:22 PM:

In message <[email protected]>, Sat, 18 Nov 2006
Dr J R Stockton said the following on 11/18/2006 3:44 PM:

<snip>

Square bracket notation is necessary if the "term" must be supplied at
run time.
That is not always true. Square bracket notation is necessary if the
"term" has characters in that JS doesn't like. PHP's array-ness of
inputs comes to mind first. If the name of the inputs is "myInput[]"
then you have to use bracket notation to access it using it's name
but the "term" will be known at programming time.

That very specific issue is dealt with in Section 4.25.
When I wrote 'Square bracket notation is necessary if the "term"
must be supplied at run time', I meant 'Square bracket notation is
necessary if the "term" must be supplied at run time'.

And my point is that your statement is false. It implies that is the
only time it is necessary and that isn't true. Perhaps if I had quoted
the previous line to the one I quoted you wouldn't be splitting hairs
about what I wrote. Because the previous line is also patently false.

I snipped everything you said that made any sense. You are a half wit
sometimes.