Iterating sparse arrays

[Mighty Krell]

Re: Iterating sparse arrays


"Douglas Crockford" <nospam@covad.n et> wrote in message
news:3d0a1$41ee 59eb$44a4af95$6 64@msgid.megane wsservers.com.. .[color=blue][color=green][color=darkred]
> >>It is incorrect to use an array when the keys are non-integers.[/color][/color]
>[color=green]
> > I think this is too strong of a statement since the array declaration
> > supports string values as references.[/color]
>
> Wrong is wrong even if you do not understand the difference.[/color]


You're full of crap. JS allows string indices on purpose. It's quite
intentional, even if you don't like it.

MK

[Richard Cornford]

Re: Iterating sparse arrays

Mighty Krell wrote:[color=blue]
> Douglas Crockford wrote:[color=green][color=darkred]
>>>> It is incorrect to use an array when the keys are
>>>> non-integers.[/color]
>>[color=darkred]
>>> I think this is too strong of a statement since the
>>> array declaration supports string values as references.[/color]
>>
>> Wrong is wrong even if you do not understand the difference.[/color]
>
>
> You're full of crap.[/color]

?
[color=blue]
> JS allows string indices on purpose.[/color]

"indices" is a potentially misleading term to use in this context, with
its connotations of numeric indices as used in Arrays.

Javascript supports bracket notation property accessors for a reason,
but that reason is mostly related to accessing the properties of Objects
with dynamically determined property names.
[color=blue]
> It's quite intentional, even if you don't like it.[/color]

There is no implication in Douglas's posts that he doesn't like bracket
notation property accessors. He is impugning the appropriateness of
using an objet specialised as an Array in circumstances where only the
general behaviour of Objects is desired.

Richard.

[Robert]

Re: Iterating sparse arrays

In article <ctk1e4$k0u$1$8 302bc10@news.de mon.co.uk>,
"Richard Cornford" <Richard@litote s.demon.co.uk> wrote:
[color=blue][color=green]
> > JS allows string indices on purpose.[/color]
>
> "indices" is a potentially misleading term to use in this context, with
> its connotations of numeric indices as used in Arrays.[/color]

But we know that javascript allows arrays to have string indexes.

from: http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?index
index

(Plural "indices" or "indexes")

1. <programming> A number used to select an element of a list, vector,
array or other sequence. Such indices are nearly always non-negative
integers but see associative array.

2. <database> See inverted index. [Other kinds?]

3. <World-Wide Web> A search engine.

4. <World-Wide Web> A subject index.

4. <jargon> See coefficient of X.

associative array

<programming> An array where the indices are not just integers but may
be arbitrary strings.

awk and its descendants (e.g. Perl) have associative arrays which are
implemented using hash coding.

from: http://en.wikipedia.org/wiki/Indices

In information technology

In computer science, an index is usually used for expressing an nth
element. Indices are usually expressed as integers.

These two definition acknowledge that people are using the term indices
to include non numeric values but these folks are in the minority. It
seems the direction is to use the term indices even if the array allow
string indexes.

I think that interpretive languages blur the distinction between numeric
only indexes to arrays and string based access to data object. The
distinction is more related to a language like C not a language like
Javascript.

I have done a lot a programming in languages with associative arrays as
the underlaying data structure used to access data. It's not a big deal
to me to use string indexes in arrays since I am used to this being the
only way to access the data.[color=blue]
>
> Javascript supports bracket notation property accessors for a reason,
> but that reason is mostly related to accessing the properties of Objects
> with dynamically determined property names.
>[color=green]
> > It's quite intentional, even if you don't like it.[/color]
>
> There is no implication in Douglas's posts that he doesn't like bracket
> notation property accessors. He is impugning the appropriateness of
> using an objet specialised as an Array in circumstances where only the
> general behaviour of Objects is desired.[/color]

This is a little to strong. Douglas objected twice to my earlier posts
when I pointed out that you could have a string index in a Javascript
array.

It seems to me that the underlaying data saving method in Javascript is
an associative array. There are two ways of accessing the data in the
associative array. One in the array syntax and the other the object
syntax.

Considering that array indices are saved as a strings, there seems to be
too much hand waving over how bad it is to use a string as an index with
an array. Also, I associate the bracket notation with array access, so
it is interesting some find it perfectly normal to use bracket notation
with an object but unacceptable to use a string an an index in an array.

Javascript aren't C so let's not apply the C language conventions to
object like arrays in Javascript.

Robert

[Douglas Crockford]

Re: Iterating sparse arrays

> It seems to me that the underlaying data saving method in Javascript is[color=blue]
> an associative array. There are two ways of accessing the data in the
> associative array. One in the array syntax and the other the object
> syntax.[/color]

The underlying structure is the object. In JavaScript, the object is the
associative array. The JavaScript array is a specialization of the
object with special features for handling numeric subscripts.

The dot notation and subscript notation both work with objects, and
since arrays are, deep down, object, both notations work with arrays, too.

It is possible to use non-numeric subscripts with arrays, but that
usually indicates a lack of understanding. Fortunately, such a lack is
easily remedied. See for example

http://www.crockford.com/javascript/survey.html

[Richard Cornford]

Re: Iterating sparse arrays

Robert wrote:[color=blue]
> Richard Cornford wrote:[color=green][color=darkred]
>> > JS allows string indices on purpose.[/color]
>>
>> "indices" is a potentially misleading term to use in this
>> context, with its connotations of numeric indices as used
>> in Arrays.[/color]
>
> But we know that javascript allows arrays to have string
> indexes.[/color]

What we know is that bracket notation allows the named properties of
Objects to be referenced using expressions that evaluate to results that
are strings, or can be type-converted to strings. We also know that
Arrays are a specialised type of the native ECMAScript object, as are
Functions, Dates, regular expressions and Boolean String and Number
objects. Whether those expressions representing object property names
are indices is a matter of the interpretation of language.
[color=blue]
> from: http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?index
> index
>
> (Plural "indices" or "indexes")
>
> 1. <programming> A number used to select an element of a
> list, vector, array or other sequence. Such indices are nearly
> always non-negative integers but see associative array.[/color]
<snip>[color=blue]
> associative array
>
> <programming> An array where the indices are not just integers
> but may be arbitrary strings.[/color]
<snip>[color=blue]
> In computer science, an index is usually used for expressing
> an nth element. Indices are usually expressed as integers.[/color]

So we have a term that would normally refer to an integer number, but
may less commonly refer to a sequence of characters (or a non-integer
number). That is precisely why I proposed that the term has connotations
of numeric indices, and so is a potentially misleading term to apply to
the accessing of the named properties of objects.
[color=blue]
> These two definition acknowledge that people are using
> the term indices to include non numeric values but these
> folks are in the minority.[/color]

And the people who read descriptions of javascript property accessors
couched in terms of 'indices' and assume that their use in the context
of an Array will provide some sort of - length - related, or iteration
effect, are also in a minority. But they would still be better off if
the terminology used in explanations made a clear distinction between
the normal behaviour of all native ECMAScript objects and the
specialised behaviour additionally provided by Array objects.
[color=blue]
> It seems the direction is to use the term indices even if
> the array allow string indexes.[/color]

In javascript it is not the Array that is 'allowing string indices', it
is the Object that allows the dynamic creation and referencing of named
properties. The Array _adds_ behaviour to an underlying native
ECMAScript object. All Arrays were native ECMAScript objects before they
were Arrays.
[color=blue]
> I think that interpretive languages blur the distinction
> between numeric only indexes to arrays and string based
> access to data object. The distinction is more related to
> a language like C not a language like Javascript.[/color]

The expressions used in bracket notation property accessors are always
type converted to strings so the distinction is blurred, to the point of
there being no apparent distinction. And with unaugmented native
ECMAScript objects there is no distinction at all.

<snip>[color=blue][color=green][color=darkred]
>> > It's quite intentional, even if you don't like it.[/color]
>>
>> There is no implication in Douglas's posts that he doesn't
>> like bracket notation property accessors. He is impugning the
>> appropriateness of using an objet specialised as an Array in
>> circumstances where only the general behaviour of Objects is
>> desired.[/color]
>
> This is a little to strong. Douglas objected twice to my earlier
> posts when I pointed out that you could have a string index in a
> Javascript array.[/color]

It is normal to discourage the promotion of misconceptions on this
group. And this group is a good place to observe which misconceptions
are common, and what factors promote them. Often they arise form
individuals applying expectations gained from other languages to
javascript. Sometimes they follow from inappropriately worded
explanations, and sometimes they follow from misguided examples (or
combinations of these). The relationship between javascript
Objects/Arrays and associative arrays and hashtables in other languages
is frequently the subject of these misconceptions.
[color=blue]
> It seems to me that the underlaying data saving method
> in Javascript is an associative array.[/color]

The implementation details are left to the authors of the interpreter to
decide. Some certainly appear to be very hashtable/associative array
like, others betray evidence of list-like implementation.

<snip>[color=blue]
> Considering that array indices are saved as a strings, there
> seems to be too much hand waving over how bad it is to use a
> string as an index with an array.[/color]

The hand waving is not about dynamically creating named properties on
Array objects, it is about promoting the misconception that this has
something to do with the Arrayness of that object, rather than its
underlying Objectness. A misconception that is promoted, at leas in
part, by the use of inappropriate terminology in the context.
[color=blue]
> Also, I associate the bracket notation with array access,[/color]

While in javascript that syntax is actually a direct parallel to dot
notation property accessors. An invaluable facility in a dynamic
language. And there is actually no specialised Array accessing syntax at
all.
[color=blue]
> so it is interesting some find it perfectly normal to
> use bracket notation with an object but unacceptable to
> use a string an an index in an array.[/color]

Nobody finds it unacceptable to 'use a string to index an array'. What
is unacceptable is using an Array object in a context where an Object
object would facilitate all that is required. The specialised objects
should be reserved for circumstances where the facilities provided by
their specialisation are necessary for the task. An Array object is
specialised for use with integer indexes and interactions using its -
length - property (along with the many integer indexed property
manipulation methods provided on its prototype). If those facilities are
not being used there is no point in having them.
[color=blue]
> Javascript aren't C so let's not apply the C language
> conventions to object like arrays in Javascript.[/color]

Who is applying C conventions? An understanding of javascript/ECMAScript
is sufficient to guide its appropriate application.

Richard.