Object instead of array? Any problems?

[julie.siebel]

I've been wrestling with a really complex page. All the data is drawn
down via SQL, the page is built via VBScript, and then controlled
through javascript.

It's a page for a travel company that shows all the properties, weeks
available, pricing, etc. for a particular area of Europe. The data
varies widely depending on the region; at times there will be 50
properties, and at other times only a half dozen.

The cross referencing of pricing information, maximum guests, etc. per
property and per date had been driving me crazy, and was requiring
what felt like 17 million arrays.

Javascript isn't my specialty, so please pardon my ignorance. I'd
never heard of using an object instead of an array, and ran across it
in a web page today. It is absolutely *perfect* for what I am doing,
but I'm concerned - it seems too easy. I'm trying to figure out what
the pitfalls are.

Is it slow? Is it incompatible with a bunch of browsers? lol - it just
seems too easy after struggling with this for a couple of days. And if
it isn't slow, is it any faster than an array search? This page has
TONS of arrays, and I'm using vbscript to actually build them into the
onclick call for each date on the page. If using Object() is an
acceptable method of doing things, it could really clean up my links.

Here is the kind of thing I am doing:

var ratetable = new Object();
ratetable["r1123"] = [800,400,300,200,0,0,0,0];
ratetable["r6543"] = [-50, -100, -150, 0, 0, 0, 0, 0];
ratetable["r2342"] = [50,50,50,50,25,25,25,25]

rvalue="r6543";
passengers=3;

alert(ratetable[rvalue][passengers-1])

In reality, clicking on a property calls a javascript function which
assigns the rvalue, and adjusts the prices for the tour based on the
number of passengers, the date, and the property selected. I also have
tables that show which properties are available by date, which dates
are available per property, lol - it's a mess. This object thingy if
it is OK to use would be SOOO great.

What am I missing here?

Thanks,

Julie

[Peter Michaux]

Hi Julie,

On Jun 6, 5:45 pm, "[e-mail]" <[e-mail]>
wrote:

It's a page for a travel company that shows all the properties, weeks
available, pricing, etc. for a particular area of Europe. The data
varies widely depending on the region; at times there will be 50
properties, and at other times only a half dozen.

The cross referencing of pricing information, maximum guests, etc. per
property and per date had been driving me crazy, and was requiring
what felt like 17 million arrays.

Javascript isn't my specialty, so please pardon my ignorance. I'd
never heard of using an object instead of an array, and ran across it
in a web page today. It is absolutely *perfect* for what I am doing,
but I'm concerned - it seems too easy. I'm trying to figure out what
the pitfalls are.

You should use an object then! I use objects far more often then
arrays. The reason is I can index into the object by the "key" and get
the "value". This is treating a JavaScript object like a hash in many
languages.

Is it slow?

Faster than hunting through a big array.

Is it incompatible with a bunch of browsers?

All of them since a long, long time ago.

lol - it just
seems too easy after struggling with this for a couple of days.

A pleasure I'm sure! :)

And if
it isn't slow, is it any faster than an array search?

If the JavaScript engine is written well then it is faster.

This page has TONS of arrays,

How much data are you loading into this web page? Is it making the
page load noticeably slowly?

and I'm using vbscript to actually build them into the
onclick call for each date on the page. If using Object() is an
acceptable method of doing things, it could really clean up my links.

Here is the kind of thing I am doing:

var ratetable = new Object();
ratetable["r1123"] = [800,400,300,200,0,0,0,0];
ratetable["r6543"] = [-50, -100, -150, 0, 0, 0, 0, 0];
ratetable["r2342"] = [50,50,50,50,25,25,25,25]

rvalue="r6543";
passengers=3;

alert(ratetable[rvalue][passengers-1])

There is an easier ways to create objects with an object literal

var ratetable = {
r1123: [800,400,300,200,0,0,0,0],
r6543: [-50, -100, -150, 0, 0, 0, 0, 0],
r2342: [50,50,50,50,25,25,25,25]
};

In reality, clicking on a property calls a javascript function which
assigns the rvalue, and adjusts the prices for the tour based on the
number of passengers, the date, and the property selected. I also have
tables that show which properties are available by date, which dates
are available per property, lol - it's a mess. This object thingy if
it is OK to use would be SOOO great.

The object thingy is ok. It is one of the best features of the
language.

Peter

[RobG]

On Jun 7, 1:43 pm, Peter Michaux <[e-mail]:

Hi Julie,

On Jun 6, 5:45 pm, "[e-mail]" <[e-mail]>
wrote:

[...]

Javascript isn't my specialty, so please pardon my ignorance. I'd
never heard of using an object instead of an array, and ran across it
in a web page today. It is absolutely *perfect* for what I am doing,
but I'm concerned - it seems too easy. I'm trying to figure out what
the pitfalls are.

You should use an object then!

[...]

Is it incompatible with a bunch of browsers?

All of them since a long, long time ago.

I think you mean *none* of them. :-)

Just about everything in javascript is an object, so if a particular
browser doesn't support objects...

lol - it just
seems too easy after struggling with this for a couple of days.

A pleasure I'm sure! :)

And if
it isn't slow, is it any faster than an array search?

If the JavaScript engine is written well then it is faster.

You can search an array using a for loop like:

var elementValue;
for (var i=0, len=someArray.length; i<len; i++){
elementValue = someArray[i];
/* do something with elementValue */
}

The object equivalent is a for..in loop:

var propertyValue;
for (var property in someObject) {
propertyValue = someObject[property];
/* do something with objectProperty or propertyValue */
}

But be aware that if someObject's prototype (or any prototype in its
prototype chain) has had properties added (bad practice but you may
stumble across it), you will iterate over those properties too.
--
Rob

[Peter Michaux]

On Jun 6, 9:33 pm, RobG <[e-mail]:

On Jun 7, 1:43 pm, Peter Michaux <[e-mail]:

Hi Julie,

On Jun 6, 5:45 pm, "[e-mail]" <[e-mail]>
wrote:

[...]

Javascript isn't my specialty, so please pardon my ignorance. I'd
never heard of using an object instead of an array, and ran across it
in a web page today. It is absolutely *perfect* for what I am doing,
but I'm concerned - it seems too easy. I'm trying to figure out what
the pitfalls are.

You should use an object then!

[...]

Is it incompatible with a bunch of browsers?

All of them since a long, long time ago.

I think you mean *none* of them. :-)

Umm. Yes, yes I did. Thanks, Rob.

Peter

[-Lost]

RobG wrote:

But be aware that if someObject's prototype (or any prototype in its
prototype chain) has had properties added (bad practice but you may
stumble across it), you will iterate over those properties too.

Adding methods or properties via the prototype property is bad practice?

I thought the general rule of thumb was you did not want to mess with
the existing JavaScript Objects' prototype chain. As in, don't augment
Array or String or whatever.

Does that mean you should only do:

var myObj = {};
myObj.attr1 = 'I am an attribute of myObj.';
myObj.func1 = function() { alert('I am a function of myObj.'); }

....?

What about how people augment String to include ltrim- and rtrim-type
functions? The FAQ even illustrates this.

Or in the case of a custom application you require all objects have the
ability to identify themselves to the calling function or expose the
context in which they were called.

How do you go about doing something like that without prototype?

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

[Erwin Moller]

ju**********@gmail.com wrote:

<snip>

In reality, clicking on a property calls a javascript function which
assigns the rvalue, and adjusts the prices for the tour based on the
number of passengers, the date, and the property selected. I also have
tables that show which properties are available by date, which dates
are available per property, lol - it's a mess. This object thingy if
it is OK to use would be SOOO great.

Hi,

I know excactly how you feel! I remember my happiness when I first started
using porperties in Objects instead of arrays. Great indeed!
I still name them hashes, just as in other languages, but many in here
demand that they are named properties. ;-)

Enjoy.

Regards,
Erwin Moller

>
What am I missing here?

Thanks,

Julie

[RobG]

On Jun 7, 7:04 pm, -Lost <[e-mail]:

RobG wrote:

But be aware that if someObject's prototype (or any prototype in its
prototype chain) has had properties added (bad practice but you may
stumble across it), you will iterate over those properties too.

Adding methods or properties via the prototype property is bad practice?

I didn't word that very well: most consider extending the Object
prototype as bad practice always, some also shun extending Array,
particularly in libraries. Extending user-defined native objects
isn't bad, as you point out below, it's required for prototype-based
inheritance.

I thought the general rule of thumb was you did not want to mess with
the existing JavaScript Objects' prototype chain. As in, don't augment
Array or String or whatever.

It's probably OK to extend objects like String, Number and Math since
if done properly it's unlilely to have adverse effects (e.g. no one
should be using them, or objects constructed from them, in a for..in
loop). However, Array and Object should be left alone.
--
Rob

[-Lost]

RobG wrote:

On Jun 7, 7:04 pm, -Lost <[e-mail]:

>RobG wrote:

>>But be aware that if someObject's prototype (or any prototype in its
prototype chain) has had properties added (bad practice but you may
stumble across it), you will iterate over those properties too.

Adding methods or properties via the prototype property is bad practice?

I didn't word that very well: most consider extending the Object
prototype as bad practice always, some also shun extending Array,
particularly in libraries. Extending user-defined native objects
isn't bad, as you point out below, it's required for prototype-based
inheritance.

>I thought the general rule of thumb was you did not want to mess with
the existing JavaScript Objects' prototype chain. As in, don't augment
Array or String or whatever.

It's probably OK to extend objects like String, Number and Math since
if done properly it's unlilely to have adverse effects (e.g. no one
should be using them, or objects constructed from them, in a for..in
loop). However, Array and Object should be left alone.

Duly noted. As always, thanks.

--
-Lost
Remove the extra words to reply by e-mail. Don't e-mail me. I am
kidding. No I am not.

[Andy Fish]

to be honest, I think you are confusing objects with associative arrays

all arrays in javascript can be indexed by text strings instead of numbers,
so there is actually little difference from your point of view between an
object and an array

<ju**********@gmail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

I've been wrestling with a really complex page. All the data is drawn
down via SQL, the page is built via VBScript, and then controlled
through javascript.

It's a page for a travel company that shows all the properties, weeks
available, pricing, etc. for a particular area of Europe. The data
varies widely depending on the region; at times there will be 50
properties, and at other times only a half dozen.

The cross referencing of pricing information, maximum guests, etc. per
property and per date had been driving me crazy, and was requiring
what felt like 17 million arrays.

Javascript isn't my specialty, so please pardon my ignorance. I'd
never heard of using an object instead of an array, and ran across it
in a web page today. It is absolutely *perfect* for what I am doing,
but I'm concerned - it seems too easy. I'm trying to figure out what
the pitfalls are.

Is it slow? Is it incompatible with a bunch of browsers? lol - it just
seems too easy after struggling with this for a couple of days. And if
it isn't slow, is it any faster than an array search? This page has
TONS of arrays, and I'm using vbscript to actually build them into the
onclick call for each date on the page. If using Object() is an
acceptable method of doing things, it could really clean up my links.

Here is the kind of thing I am doing:

var ratetable = new Object();
ratetable["r1123"] = [800,400,300,200,0,0,0,0];
ratetable["r6543"] = [-50, -100, -150, 0, 0, 0, 0, 0];
ratetable["r2342"] = [50,50,50,50,25,25,25,25]

rvalue="r6543";
passengers=3;

alert(ratetable[rvalue][passengers-1])

In reality, clicking on a property calls a javascript function which
assigns the rvalue, and adjusts the prices for the tour based on the
number of passengers, the date, and the property selected. I also have
tables that show which properties are available by date, which dates
are available per property, lol - it's a mess. This object thingy if
it is OK to use would be SOOO great.

What am I missing here?

Thanks,

Julie

[Lee]

Andy Fish said:

>
to be honest, I think you are confusing objects with associative arrays

all arrays in javascript can be indexed by text strings instead of numbers,
so there is actually little difference from your point of view between an
object and an array

No, I think you're confused.
The fact that you can seem to index arrays by text strings
is simply because arrays are Objects. It's slightly better
to use a generic Object in this way than an Array, because
the Array object has a "length" attribute and array-specific
methods that could cause confusion.
--

[Peter Michaux]

On Jun 7, 8:52 am, "Andy Fish" <[e-mail]:

to be honest, I think you are confusing objects with associative arrays

There isn't something called and "associative array" in JavaScript.
All objects (including arrays and functions which are objects) can be
used as an "associative array".

all arrays in javascript can be indexed by text strings instead of numbers,

This is because arrays are objects.

so there is actually little difference from your point of view between an
object and an array

If you want to use an "associative array" concept then it is
conceptually simpler to use an plain object since the arrayness of an
array object won't be utilized.

Peter

[scripts.contact]

Peter Michaux wrote:

The object thingy is ok. It is one of the best features of the
language.

I agree :)

[scripts.contact]

Peter Michaux wrote:

The object thingy is ok. It is one of the best features of the
language.

I agree :)

[julie.siebel]

So I sent an post earlier and I either did something wrong or Google
groups ate it.

In essense it said (and then some, because I can't seem to shut
up :P):

Thanks to everyone for all your help (via the Group and through
email)!

I don't entirely understand everything you are talking about, but I
think I got the jist of it enough to get started.

In case anyone wondered, the whole point of this page is that it is
replacing the search and selection for a complicated sort of trip (for
this company, anyway). No searching will be necessary - all the
availability/pricing/properties/persons will be in a single page that
never has to reload because a search didn't yield the options the
customer was looking for. Should be easier on the server.

I'm redoing the javascript arrays/functions and stored procedures/
vbscript for the page now. I'm going to see if my client will allow me
to post the test page here. This stuff is much easier to show than it
is to explain. I'm assuming there are going to be speed issues when it
is complete (though it loads pretty quickly) and I'm wondering if I
SHOULD make certain "tables" of data into standard arrays.

Thanks again for your help. You guys are incredible.

Julie

[ron.h.hall]

On Jun 7, 4:55 am, RobG <[e-mail]:

On Jun 7, 7:04 pm, -Lost <[e-mail]:

RobG wrote:

But be aware that if someObject's prototype (or any prototype in its
prototype chain) has had properties added (bad practice but you may
stumble across it), you will iterate over those properties too.

Adding methods or properties via the prototype property is bad practice?

I didn't word that very well: most consider extending the Object
prototype as bad practice always, some also shun extending Array,
particularly in libraries. Extending user-defined native objects
isn't bad, as you point out below, it's required for prototype-based
inheritance.

I thought the general rule of thumb was you did not want to mess with
the existing JavaScript Objects' prototype chain. As in, don't augment
Array or String or whatever.

It's probably OK to extend objects like String, Number and Math since
if done properly it's unlilely to have adverse effects (e.g. no one
should be using them, or objects constructed from them, in a for..in
loop). However, Array and Object should be left alone.

In general, as you note, there's little issue about augmenting some
built-ins through the prototype mechanism. There's been long-standing
controversy over augmentation of Array and, and in particular for,
Object.

In Javascript, the good news is that Object.prototype augmentation can
and does have and effect on all objects. The bad news is that
Object.prototype augmentation can and does have and effect on all
objects.

Concentrating on Object, the "worst" case, it seems there are the
majority who like to play it safe and avoid any interference that
might be caused by augmentation by way of Object.prototype. On the
other hand, there are those including myself, who see such avoidance
as a restriction on the capabilities which a prototyping language such
as Javascript is designed to provide.

The underlying problem that arises when Object.prototype is augmented
is that the property namespace expands, and where there was formerly
an expectation that property resolution occur only within a local
object (or within a constructed prototype chain), that no longer
pertains. In particular, "for .. in" loops give rise to delivery of
properties that are not necessarily local to the object upon which
iteration is being carried out.

Nonetheless, this circumstance is not all that different from that in
which the language is being used as intended, with prototypal
inheritance prescribed through the use of constructor prototypes for
user-created object extensions. The programmer, in general, needs to
be fully aware of the prototypal property resolution and, among other
things, be prepared to filter with "hasOwnProperty" in situations
where read resolution, including "for ... in" iteration, is to be
constrained to the immediate object.

Including a "hasOwnProperty" test or filter where required is somewhat
onerous, and not all that pretty as compared to having a clean loop.
So, if one has decided to augment Object.prototype, in my view, the
first augmentation that should be created is an iterator constructor
that will facilitate the iteration of Object objects, Array objects,
(and possibly other built-ins) and user-defined object extensions.

For my own projects, I have a personal library which provides
augmentation to Object and Array, as well as provision of other
utility services. One of the advantages of having an iteration
facility is that it is no longer necessary to choose an iteration
construct based on type of the object, e.g., Object or Array - the
iterator decides what set keys to use in the iteration, and provides
keys and values to the iteration loop in accordance as properties of
the iterator object.

So almost invariably iteration appears as:

var it = obj.iterator(); // [1]
while (it.next()) {
alert("key: " + it.k + " value:" + it.v); // Display local key,
value, e.g.
}

and seldom is seen a "for(..;..;..)" or "for (... in ...)" looping
construct.

Whereas little is lost in execution efficiency, much is to be gained
in terms of uniformity and overall augmented facility brought to hand.

____________

[1] Care is still required with the expanded namespace. _iterator, or
some such, would be a better choice of name, perhaps, to help prevent
the possibility of conflicting override within an object.
--
../rh