|
|
Posted by Michael Winter on 07/20/05 14:37
On 20/07/2005 09:16, ^reaper^ wrote:
> [Michael Winter wrote:]
>
>> 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!
Believe what you will. I have defined a situation where iterating of an
object /can/ lead to unwanted behaviour. I have access to a limited
subset of scriptable browsers, so I don't know if that behaviour /will/
occur, but if I am writing code that may be used by others, I try to
ensure that it is robust. You've already stated that you aren't
interested in that level of caution (here at least), and are quite happy
to have 'working' code. That's your decision.
>>> 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 /do/ want to play OMH's little games, eh?
You previously wrote:
"However, since teh array has a built in hashing feature for direct
access as well as teh iteration feature for list walking"
to which I replied:
"There is no hashing in ECMAScript; square bracket notation is a form
of property accessor and is a feature of all objects."
I never commented on implementation-specific details (you started that),
but simply stated that there is no notion of hashes in ECMAScript. There
are objects, and objects have properties. The syntax that ECMAScript
provides allows code to /look/ like some kind of hash is involved, and
in simple cases an object can be used /like/ a hash table, but it isn't
one. There is no backpedal here - you just want to troll.
[snip]
>> If I was referring to your code specifically,
>
> Which is what we are discussing.
We have discussed several things. Your code may have been used during
the discussion, but it hasn't been solely about that code.
[snip]
> If teh constructor indeed behaves inconsistently when passing it a
> lits of strings, then please do explicate.
When did I say that the constructor for behaves inconsistently with
strings? Didn't I just say that I wasn't referring directly to your
code? Once again, you are reading what you want to read, and ignoring
what you want to ignore.
new Array(4)
new Array('4')
new Array(4, 4)
new Array(4294967296)
These all behave differently. What would:
new Array(x)
do?
The array literal performs consistently in all of those cases, so I use
it whenever I creating an Array object, and I would use in your case,
too. Not because there are specific problems in your case, but because I
choose to have uniformity in my code.
[snip]
> I'm using [the length property] for pv & saved. Tested locally, but not updated on teh server.
With your current markup, all calls to the update function pass a string
that contains a letter or word for the second argument, k. So, when k is
used as a property name for the 'array', pv, that property name is not
an array index and will not alter the length property:
var a = []; alert(a.length); // 0
a[0] = 'a'; alert(a.length); // 1
a['A'] = 'b'; alert(a.length); // 1
a[1] = 'c'; alert(a.length); // 2
a['fortune'] = 'd'; alert(a.length); // 2
alert(a); // a,c
[snip]
>>> 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.
Fine misquoting there.
[snip]
> I take it you aren't familiar with teh Zodiac Killer case and
> forensic profiling?
No, I'm not, which is why I asked if the symbols were significant.
[snip]
>>> 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.
I was referring to the name attributes, which is why I then said:
>> You may have changed them [the name attribute to id attributes] in the
>> meantime, but how am I supposed to know that?
I apologise for not being clear.
>>> And guess what? It /does not work/ with firefox.
>>
>> Yes, it does.
>
> /me checks page with firefox for teh umpteenth time.
>
> Nope. Still b0rked.
It's all broken at the moment because you have a hash (#) at the start
of line 15 which is causing a syntax error.
[snip]
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Navigation:
[Reply to this message]
|