Naming problem on array object

[Cylix]

I have a array to store some student information, eg
var s = new Array('2006001', 'Apple Joker', '5B');

normally, We get the data using s[0], s[1],s[2] ...
How can I define them more readable like
s['studentID'], s['studentName'], s['class'] ?

Thank you

 

[Erwin Moller]

I have a array to store some student information, eg
var s = new Array('2006001', 'Apple Joker', '5B');

normally, We get the data using s[0], s[1],s[2] ...
How can I define them more readable like
s['studentID'], s['studentName'], s['class'] ?

Make an Object of it instead of an array.
Objects behave like / are hashes.
eg:

var myClass = new Object();
myClass["studentID"] = 123;
myClass["studentName"] = "Cyclix";
etc.

Regards,
Erwin Moller

 

[Cylix]

var myClass = new Object();
myClass["studentID"] = 123;
myClass["studentName"] = "Cyclix";

Thank you for your suggestion first,
Under this way,
Can I still using myClass[0], myClass[1] to get the value?

 

[RobG]

Erwin Moller wrote:

var myClass = new Object();
myClass["studentID"] = 123;
myClass["studentName"] = "Cyclix";

Thank you for your suggestion first,
Under this way,
Can I still using myClass[0], myClass[1] to get the value?

No.

Object properties can only have one name, which is a string. You can
call them '0', '1', '2', etc. but then you might as well use an Array.

You should probably check the FAQ on how to access properties using
square brackets and dot notation:

<URL:http://www.jibbering.com/faq/#FAQ4_39>

 

[Laurent Bugnion]

Hi,

Erwin Moller wrote:

var myClass = new Object();
myClass["studentID"] = 123;
myClass["studentName"] = "Cyclix";

Thank you for your suggestion first,
Under this way,
Can I still using myClass[0], myClass[1] to get the value?

No.

Object properties can only have one name, which is a string. You can
call them '0', '1', '2', etc. but then you might as well use an Array.

You should probably check the FAQ on how to access properties using
square brackets and dot notation:

<URL:http://www.jibbering.com/faq/#FAQ4_39>

If you have to, you could do this:

var myArray = new Array();
myArray[ 0 ] = myArray[ "myLabel1" ] = anObject;

This way the property is referenced by index and by label. However, I
would avoid that if I were you, it introduces some level of confusion as
to what the container really does.

Not even mentioning that you must always remember to delete both
references, or else the referenced object won't be garbage collected.

HTH,
Laurent

 

[RobG]

Hi,

Cylix wrote:

[...]

Can I still using myClass[0], myClass[1] to get the value?

No.

[...]

If you have to, you could do this:

var myArray = new Array();
myArray[ 0 ] = myArray[ "myLabel1" ] = anObject;

This way the property is referenced by index and by label. However, I
would avoid that if I were you, it introduces some level of confusion as
to what the container really does.

Not even mentioning that you must always remember to delete both
references, or else the referenced object won't be garbage collected.

Not at all - JavaScript isn't C++

Are you aware of any browser that won't run garbage collection once a UA
navigates away from a page[1]? If it's necessary at all, then:

myArray = null;

should to the trick, provided myArray was the only reference to the
object until recently referenced by myArray and other variables don't
hold any references to whatever it formerly referenced.

1. Other than the IE memory leak noted in the FAQ, which only occurs in
a specific circumstance that shouldn't be an issue here.

 

[Laurent Bugnion]

Hi,

Hi,

Cylix wrote:

[...]

Can I still using myClass[0], myClass[1] to get the value?

[...]

If you have to, you could do this:

var myArray = new Array();
myArray[ 0 ] = myArray[ "myLabel1" ] = anObject;

This way the property is referenced by index and by label. However, I
would avoid that if I were you, it introduces some level of confusion
as to what the container really does.

Not even mentioning that you must always remember to delete both
references, or else the referenced object won't be garbage collected.

Not at all - JavaScript isn't C++

Are you aware of any browser that won't run garbage collection once a UA
navigates away from a page[1]? If it's necessary at all, then:

myArray = null;

should to the trick, provided myArray was the only reference to the
object until recently referenced by myArray and other variables don't
hold any references to whatever it formerly referenced.

1. Other than the IE memory leak noted in the FAQ, which only occurs in
a specific circumstance that shouldn't be an issue here.

In the last web application I worked on (a building automation
management station), we have situations where a page isn't posted back
for 2 weeks at least, all the values on the page being refreshed every
30 seconds using AJAX. So believe me, memory is critical in such
situation. The whole "The page is going to be refreshed anyway" attitude
was valid 3 to 5 years ago, it's not anymore!

JavaScript is not C++... it's much more flexible and it's much easier to
make mistakes and to create huge memory leaks, believe me (been there
done that). It's even more important in JavaScript than in C++ (or at
least than in C#) to program cleanly and to avoid confusing scenarios.
The one where an array contains both indexed values and properties seems
confusing enough to me to recommend against it.

HTH,
Laurent

 

[McKirahan]

I have a array to store some student information, eg
var s = new Array('2006001', 'Apple Joker', '5B');

normally, We get the data using s[0], s[1],s[2] ...
How can I define them more readable like
s['studentID'], s['studentName'], s['class'] ?

var studentID = 0
var studentName = 1
var class = 2

Thus, s[0] = s[studentID].

Except that "class" is a reserved word.

 

[RobG]

Hi,

Laurent Bugnion wrote: [...]

Not even mentioning that you must always remember to delete both
references, or else the referenced object won't be garbage collected.

Not at all - JavaScript isn't C++

Are you aware of any browser that won't run garbage collection once a UA
navigates away from a page[1]? If it's necessary at all, then:

myArray = null;

should to the trick, provided myArray was the only reference to the
object until recently referenced by myArray and other variables don't
hold any references to whatever it formerly referenced.

1. Other than the IE memory leak noted in the FAQ, which only occurs in
a specific circumstance that shouldn't be an issue here.

In the last web application I worked on (a building automation
management station), we have situations where a page isn't posted back
for 2 weeks at least, all the values on the page being refreshed every
30 seconds using AJAX. So believe me, memory is critical in such
situation. The whole "The page is going to be refreshed anyway" attitude
was valid 3 to 5 years ago, it's not anymore!

That is something of an extreme case, I'd expect that provided you
aren't constantly creating new objects and variables, it shouldn't be
an issue. I'm currently working on an intranet data entry, reporting
and workflow application with pages that will persist for some time,
hopefully not 2 weeks at a time!

JavaScript is not C++... it's much more flexible and it's much easier to
make mistakes and to create huge memory leaks, believe me (been there
done that). It's even more important in JavaScript than in C++ (or at
least than in C#) to program cleanly and to avoid confusing scenarios.

Which is better/worse is moot, but I take your point that memory
management should always be considered and if necessary, addressed.

Memory leaks in JavaScript *should* only be a product of a faulty
environment. If a script simply keeps adding more and more objects or
variables, it is plain poor coding that will cause problems
(eventually) in any language.

The one where an array contains both indexed values and properties seems
confusing enough to me to recommend against it.

Absolutely. The first question is what is the benefit of the same
object having two properties synchronised to the same value? And is
whatever benefit is gained worth the overhead of managing the object's
properties manually?

I expect that discussion to be specific to a particular circumstance -
such as a page that is updated at 30 second intervals (via AJAX?) and
not refreshed for 2 weeks.

 

[Cylix]

Actually, I just want to declaire something like the javascript style.
For example, we may reference a frame as
window.frames[0] or window.frames['ABC']

so, does it mean the design of javascript is poor in this case?

 

[Danny]

Define more readable? you mean, define names instead of an index, define away, will do both,
just like on most languages.

Danny

 

[RobG]

Actually, I just want to declaire something like the javascript style.
For example, we may reference a frame as
window.frames[0] or window.frames['ABC']

so, does it mean the design of javascript is poor in this case?

No. That is the first time you've mentioned replicating DOM behaviour,
you have yet to show a reason why that feature should be a native part
of the language and is required in a general case. If you are prepared
to set out a case for it, maybe I'll agree (or not). ;-)

Array and Object objects are native, built-in ECMAScript objects. The
frames object is a DOM 0 host object that implements the HTMLCollection
interface (it isn't part of the ECMAScript language specification or
the W3C DOM specification):

W3C DOM HTML Collection:
<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506>,

MSDN Frames collection:

<URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/collections/frames.asp>

Collections behave a bit like arrays in that they have a special,
self-adjusting length property - but otherwise they are very much like
plain objects.

 

[Dr John Stockton]

JRS: In article <44a98784$0$2017$5a62ac22@per-qv1-newsreader-
01.iinet.net.au>, dated Tue, 4 Jul 2006 07:08:31 remote, seen in

1. Other than the IE memory leak noted in the FAQ, which only occurs in
a specific circumstance that shouldn't be an issue here.

Which bit of the newsgroup FAQ is that? I can't find it in 8.1 of
2005-11-05.

 

[Douglas Crockford]

Actually, I just want to declaire something like the javascript style.
For example, we may reference a frame as
window.frames[0] or window.frames['ABC']

so, does it mean the design of javascript is poor in this case?

window.frames is a feature of the DOM, not of JavaScript. Does the DOM contain
examples of poor design? Absolutely.

 

[Laurent Bugnion]

Hi Rob,

That is something of an extreme case, I'd expect that provided you
aren't constantly creating new objects and variables, it shouldn't be
an issue. I'm currently working on an intranet data entry, reporting
and workflow application with pages that will persist for some time,
hopefully not 2 weeks at a time!

Extreme, I don't know. With AJAX coming stronger and stronger, this case
will probably occur more in the future. But I agree that when we started
doing that, we found out that IE was totally not made for this kind of
things, and we had huge memory leaks.

(when you were using web services to update the page, and when the user
would refresh the page anyway using a full postback, we would lose up to
2MB memory each time!!) Also, the HTC component that Microsoft used to
ship to make using web services easier was also causing huge leaks.

In fact, one of IE's "security" updates last year was for us (Siemens),
in order to correct some of the problems we found out when doing this
kind of things. Also, the HTC component was marked "unsupported" about 2
weeks after we reported the problem, we take credit for that (should we
take credit for Atlas too? Nah, that's a bit too much ;-)

Which is better/worse is moot, but I take your point that memory
management should always be considered and if necessary, addressed.

My point was just that even though JavaScript is "only" a scripting
language, when using it intensively you risk the same problems than with
a "conventional" programming language.

Memory leaks in JavaScript *should* only be a product of a faulty
environment. If a script simply keeps adding more and more objects or
variables, it is plain poor coding that will cause problems
(eventually) in any language.

Client-side JavaScript has that particularity that you have to run it on
a platform that you didn't design (aka the web browser). In the web
browser, many memory leaks are caused when the HTML rendering engine,
the JavaScript engine and the CSS engine interact and risk creating
circular references. Such a circular reference cannot be garbage
collected even on a page refresh. That was actually our main issue
(especially with the HTC component, which encapsulates JavaScript and
references it with a CSS construct, making it damn easy to create this
kind of circular reference).

Absolutely. The first question is what is the benefit of the same
object having two properties synchronised to the same value? And is
whatever benefit is gained worth the overhead of managing the object's
properties manually?

I expect that discussion to be specific to a particular circumstance -
such as a page that is updated at 30 second intervals (via AJAX?) and
not refreshed for 2 weeks.

Well, in the beginning, IE would die in agony after less than one day.
Reaching 2 weeks was quite an achievement we're proud of ;-)

HTH,
Laurent