|
|
Posted by ^reaper^ on 07/20/05 11:16
While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.hackers.malicious, and hastily inscribed the following
unintelligible Sanskrit in
<news:5jLCe.72127$G8.43979@text.news.blueyonder.co.uk>:
> On 18/07/2005 09:26, ^reaper^ wrote:
[...]
>> So... you did not really mean to write, "Host properties are
>> implementation specific" *as if* that actually means summit? o_O
>
> I don't write code where it becomes an issue.
Xlation: I haven't teh faintest clue what Array object scenarios (involving
string indicies) could cause issues. But I saw it on teh interweb, so it
must be true!
>> I wasn't teh one who unequivocally stated, and I quote, "There is no
>> hashing in ECMAScript" *shrugs*
>
> There is no hashing in the language. An implementation might use a hash
> table to store object properties but, whilst it is the most efficient,
> it's not the only possible implementation.
Uh-oh. Backpedal. o_O
>> So... you're saying constructing an Array of /simple strings/ behaves
>> inconsistently? *boggle*
>
> The constructor behaves differently based on the number and type of
> arguments. If I was referring to your code specifically,
Which is what we are discussing. Or have you not noticed teh parenthetical,
"in this case" comments throughout this thread? o_O
> you wouldn't have needed me to tell you'd have problems.
Which I'm not. Having problems that is. For either teh paired values *or*
teh enumerated lits. Positioning and update of teh dom element data /in
firefox/ is another story altogether.
> You'd have discovered that yourself. Similarly, I said that I would
> use an array literal - I never said you had to.
Again. The question is why the array literal over the constructor (for this
particular case). You noted you /prefer/ the literal over the constructor
due to inconsistent constructor behavior. If teh constructor indeed behaves
inconsistently when passing it a lits of strings, then please do explicate.
Otherwise, your /inconsistent/ comment looks like nothing more than a poor
attempt in technical, yet meaningless, hyperbole to bolster your preferred
approach.
>>> Do you use the length property of those arrays? No.
>>
>> Yes.
>
> You use the length properties of the arrays that are properties of the
> map object, and I acknowledged that in a previous post, and I'm not
> referring to it. Do you use it for any of the other objects? No.
I'm using it for pv & saved. Tested locally, but not updated on teh server.
I actually thought you might have a valid point wrt your Object object
position, so I figured I'd wait and see. After all, why update teh server
with code that I could very well be replacing anyway? Put another way, I
assumed you knew what you were talking about (since you're teh ECMAScript
guru and I am not). I'm still waiting. o_O
>>> Do you use any of the Array.prototype methods? No.
>>
>> join.
>
> Where? I don't see it in any of the script files.
I'm using it for teh cookie serializaiton bit. Also tested locally, but not
yet updated on teh sever (see above, rinse, repeat).
>> The implied behavior [of Arrays] is iteration, slicing, splicing, sorting,
>> popping, pushing, shifting, reversing, joining, etc. In other words, /list
>> management/. Since I am dealing with /list management/, guess what? Teh
>> Array object seems to be teh logical choice.
>
> Those methods work with elements that have array indices. That is,
> property names that satisfy the following expression:
>
> ToString(ToUint32(name)) == name
>
> where name is the Identifier or Expression evaluated and converted using
> the internal ToString operator.
>
> None of the properties in your objects satisfy that expression so they
> are not array indices and none of the Array.prototype methods will act
> on them.
That's odd, bc teh array indices (which are strings in this case) as well
as teh join appears to be working fine. Must be some sort of ECMAScript
impl fluke, eh? o_O
>> Unless of course, a) js Arrays are as erratic as you appear to be
>> proposing
>
> I'm not proposing that they are erratic at all.
Oh. Okay. So you did not mean to imply they behave erratically, when you
wrote this?
Host properties are implementation specific. In certain
circumstances, simple enumeration works.
Odd that.
> They have well-defined behaviour that you don't seem to understand.
You may very well be right. Perhaps I do not understand them. At all. After
all, I've always viewed Array objects as nothing more than structured data
containers. Which, in teh case of ECMAScript, also provides list management
features through their prototypes. In fact, I've always viewed ECMAScript
as a somewhat simplististically primitive lang with a limited usefulness.
But that's neither here nor there wrt this thread. *shrug*
>> Put another way. I'm looking for a concrete technical reason (just
>> one) not to use an Array object (in this scenario). Which you have
>> yet to provide.
>
> I have on more than one occasion. If you are unable to see it, fine. I'm
> not going to waste my time, particularly when considering the direction
> this conversation is taking. I should have known better.
All you have done thus far is to make vague allusions to hypothetical
behavior. In fact, you seem to be approaching this from teh Array objects
are bad, Object objects are good, pov, to teh point of using non-existent
hypotheticals to support your position, while contradicting yourself left
and right. This leads me to wonder if you bought someone's opinion without
fully fleshing out teh underlying issues that drove their opinion in teh
first place. Do however feel free to prove me wrong.
>> Oh ffs. Why on earth would I /even use/ teh graphic symbols in teh /first
>> place/, if teh ISO-8859 *already* supported *all* of teh symbols? Maybe cuz
>> it doesn't. Yathink? o_O
>
> Can information be derived from the symbols themselves? For instance,
> would replacing all occurrences of theta with, say omicron, prevent
> someone from breaking the cipher? If not, then it doesn't matter which
> symbols you use, does it?
I take it you aren't familiar with teh Zodiac Killer case and forensic
profiling? Put another way, of course teh symbols are important. It's not
like teh guy just pulled some symbols otter his ass or juiced a cracker
jack decoder ring to gen teh ciphertext. He /chose/ teh symbols for a
reason, and that reason (teh meaning he attached to teh symbols) plays a
part in decoding his ciphers. In fact, several research articles have been
written in this regard. So replacing a theta (which does exist in teh
ISO-8859) with say, an omicron, would be ten shades of stupid, as it
obliterates what clues teh symbols themselves may hold. Doink! o_O
>> You really should consider reading up on visual impairment issues.
>
> If text is too small to read, then it is too small. For example, an
> eight which appears on the symbol table is but a blur to me. It wouldn't
> matter what colour it is, as it's the small size that's the problem.
Sure, and that small size would not be changed by placing teh symbols in
teh cell /unless/ I used teh same impl that I did in v1 (e.g., displaying
teh freq pairs in teh cell as superscript chars). *shrug*
>> You simply engaged in (somewhat amuzing) logical fallacy
>> acrobatics and I was in teh mood to play. ^_~
>
> I did nothing of the sort.
Perhaps you did not intend to, but okay. o_O
>>> You cannot use the getElementById method to reference the INPUT
>>> elements in the symbol table unless you give them all id
>>> attributes.
>>
>> Yes. I read you teh first time you psoted this comment and added /id
>> attributes/ to teh "INPUT elements." In fact, it was one of teh first
>> things I did after reading your first response to this thread.
>
> They were still there yesterday. You may have changed them in the
> meantime, but how am I supposed to know that?
You are quite correct. Teh id attributes were still there 'yesterday' and
they are still there 'today'. Fancy that! As I so noted earilier, I found
much of your feedback quite helpful, and made teh changes accordingly.
>> And guess what? It /does not work/ with firefox.
>
> Yes, it does.
/me checks page with firefox for teh umpteenth time.
Nope. Still b0rked.
>> I'm admittedly disappointed in you, Michael.
>
> For providing an example?
For being predictably a^Hprecise when it comes to attending to detail while
missing teh obvious. Idunno. You do teh math. o_O
--
"The right to be heard does not automatically include the right to be taken
seriously." -- Hubert Humphrey
Navigation:
[Reply to this message]
|