Posted by ^reaper^ on 11/12/81 11:22

While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600,alt.html, and hastily inscribed the following unintelligible
Sanskrit in <news:US7Ce.71125$G8.64586@text.news.blueyonder.co.uk>:

> On 16/07/2005 03:04, ^reaper^ wrote:
>
>> However, since teh array has a built in hashing feature for direct
>> access as well as teh iteration feature for list walking
>
> There is no hashing in ECMAScript; square bracket notation is a form of
> property accessor and is a feature of all objects. The single difference
> between it and dot notation is that the former evaluates an expression,
> converts it to a string, and uses that as the property name, rather than
> using a token that matches the Identifier production.

For one, ECMAScript objects aren't "true" objects, in teh purist sense
Neither is Java or C++, for that matter. Furthermore, teh ECMAScript
compiler impl is dependent upon teh compiler developer (e.g., web browser
cos, app server cos, etc). So it's up to each individual company to
/interepret/ *and* /adhere/ to teh standards as they are put forth in teh
ECMA standards guide. Which btw, is teh primary reason you end up with
xBrowser compat probs for js in teh first place. And finally, yes. I know
what the bracket doohickies are for. The point waaaas, from my read of teh
various ECMA compiler impls, teh underlying implementation of string
literal Array keys, involves a hashing algorithm. Which does not exist for
/arrays/ in modular, structural, or objectified langs. But anyway...

> Similarly, the for..in statement is a property enumerator, and also
> functions with all objects.
>
> Neither are features of the Array object, but are inherited from the
> Object object.
>
> The only arrays that you need are elements within map, and I would use
> array literal syntax for them:
>
> map.H = ['x0y0', 'x2y15', 'x17y11', 'x19y3'];

Well, given teh js is autogen'd it would be an easy to change. Though, I
honestly do not see why this:

map['H'] = new Array('x0y0', 'x2y15', 'x17y11', 'x19y3');

bothers you so much. Afterall, teh end result is teh same. And accessing
teh value at runtime does not change. Or... is it teh fact that I'm juicing
a string literal accessor versus teh dot notation that niggles you? Or...
that I'm juicing teh new to call teh obj's constructor? o_O

> The map, mask, saved, and pv objects themselves should be Object objects.

For one, teh map and mask are static associative collections, with teh map
being teh only object to potentially contain one to many relationships for
any given symbol. Whereas teh saved and pv are dynamic associative
collections, purely for containing runtiime state. Furthermore, I could
make numerous arguments against using arrays, in general. And I often do.
In most cases, I find arrays to be sloppy and unnecessarily compute
intensive when there are so many more viable options. Put another way, I
did not choose teh array route without some aforethought. So, again, teh
question remains, even if I did convert teh arrays to objects, what does it
buy me? And yes, I'm still asking this question. Even after a quick reread
of both teh Object object and teh Array object in teh Standard ECMA-262,
3rd ed (I thought I might be missing some mysterious thing), I am still not
seeing (for /this/ particular scenario) why you're so intent on an Object
impl over an Array impl...

Teh biggest thing I'm seeing here (and I may be misreading you), is teh
impression you're arguing for computing teh plaintext positioning on teh
client-side... In fact, iirc, you mentioned just such a thing in your last
psot. Which would certainly support your argument for objects over arrays.
If that /is/ the case however, it's like... Idunno... ten shades of wrong.

> [snip]
>
>>> Creating a proper Map object would be more involved, yes, but a more
>>> robust solution.
>>
>> Robust in what way?
>
> Properties defined by the specification are not enumerable. All
> user-defined properties are (including those propagated through
> prototypes). Host properties are implementation specific. In certain
> circumstances, simple enumeration works. In others, it will include
> properties that wouldn't want. That isn't robust. If 'working' is good
> for you, fine.

Well yeah. That's the point I've been trying to make all along. This
particular scenario is /simple/ and requires nothing more than a simple
impl. We /are/ talking about associative collections here and only one of
two possible operation reqs; either a) direct access of teh plaintext value
via its accessor or b) iteration. Which again, is teh purpose behind teh
Array object in teh first place. If, otoh, I required specialized behavior
/and/ I were not dealing with an associative collection, then sure, I could
certainly see where an Object object would be preferrable.

Perhaps I'm being dense here. But this isn't rocket science. At least, I
don't think so.

To wit: I have a set of symbols which teh user will attempt to guess teh
paired plaintext value (thus teh menu text inputs). These symols appear
either singularly or in multiple places on teh ciphertext canvas. When the
user enters the plaintext value, I (being teh js script) want to update teh
ciphertext canvas. Since I (being teh js script) have no idea where on teh
canvas those symbols reside, I (being teh js script) access teh info from
teh map by using teh symbol's string literal as my accessor. The map will
return lits of one or more positions. Teh positions (in this impl) are
nothing more than a dom element id, whose data value I will then set to teh
plaintext that was entered. I also set teh value of teh text input field
for teh related symobol in teh form. The latter only being required when
restoring saved data (though I that step is included in teh update fn to
avoid redundant code).

Very simple. And quite straight forward, in fact. Now, if you're predicting
some hidden future situation that could potentially negatively impact teh
above, thereby increasing complexity, please do share. But unless you can
provide a concrete example, I'm inclined to believe your argument (at this
point) is based upon pure speculation of non-existent preceived problems
(in this case only).

As for teh environment dependent specifics, you certainly have valid
arguments wrt teh way I've handled setting teh document element values
(e.g., form text input & divs). So while that still needs to be addressed,
it has not a thing to do with teh Array v Object question.

> [snip]
>
>> [A table] works great /until/ you start futzing around with... say,
>> the browser text size options.
>
> With your current situation, nothing short of including separate images
> for each symbol will solve problems related to text resizing. Anything
> else would be a half-measure.

I can solve that problem just as easily with divs and explicit positioning
to obtain teh same results that I do by including teh graphics in
individual table cells. The primary diff between teh two solns (as I have
previously noted) involves dl'ing multiple tiny graphics v two single
compressed files. That, along with teh fact that teh user must hit teh
server every time they want to update teh ciphertext canvas is teh primary
diff btwn v1 & v2. And in fact, teh primary reason I even decided to go teh
overlay route (which required teh js), in teh first place. To see what I
mean by teh diffs, here's teh original impl (which, of course, works in
firefox): http://www.spyderware.net/zodiac-v1

> The reason for resizing text is to make it more readable, but if your
> preferred font size (for layout purposes) is too small, then the symbols
> (and green text) probably will be as well.

It does not assign a specific font size, rather, it assigns medium, small,
x-small, thereby relying upon teh user's browser settings to set teh
displayed size.

> So on that point, worrying about text resizing is a waste of time
> (unless you want to avoid images altogether).

In which case (by your argument), may as well just take teh page down.
After all, without teh symbol graphics, there is nothing to solve. o_O

> [snip]
>
>> I suppose I could throw teh width into teh div container... hang on,
>> brb. Nope, still doesn't work.
>
> DIV elements do not have width attributes. Use CSS and em units (if you
> still want to cling to resizing), not pixels.

Doink! That's what I get for staying up til teh wee hours!

>> Though it doesn't really matter afaics, as teh menu controls (e.g.,
>> save, refresh, mask, rots, etc) which are contained in their own
>> table, do wonky things as well.
>
> For the same reason as the INPUT elements in the previous table.
> Solvable in the same way, too.
>
>> That, and teh js does not appear to work with firefox eider.
>
> You either forgot or ignored what I said about using the getElementById
> method with name attributes.

/me checks your other message

Yep. Here it is:

<news:VhQAe.68163$G8.60573@text.news.blueyonder.co.uk>:

from the updateFunction. Here, k is a string which represents the
/name/of a form control. IE has a bug where it will return an
element with a matching name attribute if it cannot find one with
a matching id attribute. You could reference the element via the
form, or you could pass a reference to it directly and use the
name property to act as the property name on lines 11 and 13. You
should also move this line outside the loop.

Nope. Didn't ignore /or/ forget. Misunderstood/mis-impl'd? Obviously. o_O

--
"Human beings, vegetables, or comic dust, we all dance to a mysterious
tune, intoned in the distance by an invisible player" -- Albert Einstein

[Back to original message]