|
|
Posted by Michael Winter on 07/21/05 14:03
On 21/07/2005 07:26, ^reaper^ wrote:
[snip]
> In my opinion, attempting to design for behavior that /might/
> occur seems a fool's journey.
And you are welcome to that opinion, but when there are /reasonable/
scenarios where unwanted behaviour might occur, I see no justification
for ignoring such situations.
For instance, let's say that every single scriptable browser will
prevent enumeration of host properties, in addition to those listed in
the specification. Well what if you have added your own properties to
the Object.prototype object? Not an unreasonable thing to do, but it
would cause your code, as written, to fall over. Assuming the properties
added to the prototype aren't of the same type as the properties you're
trying to enumerate, you could test each one with the typeof operator
before using it, but if not, enumeration with for..in isn't safe. Of
course, your current code wouldn't be used anywhere else, but this was
just an example.
> In fact, I would further argue, attempting to design for all possible
> browser/rev scenarios is a fool's journey.
Not really,
> Esp when designing & implementing professional sites.
....and I would certainly disagree there.
It is unrealistic to expect all scriptable browsers to be capable of the
same things, of course, but that doesn't mean one cannot cater for them,
and at the same time, all user agents that do not implement client-side
scripting.
The first thing is to recognise that browser detection is a waste of
time. One cannot hope to know every browser and what it can do, nor can
one necessarily predict what known browsers will be capable of the
future (bugs might be fixed, new features might be added, etc.).
Instead, one should use feature detection and a defensive approach to
identify precisely what any given user agent can accomplish. None of
this sort of rubbish:
if(document.getElementById) {
var coll = document.getElementsByTagName('div'),
temp = document.createElement('ul');
/* ... */
}
The detection process is one-to-one:
var coll, temp;
if(document.createElement && document.getElementsByTagName
&& (temp = document.createElement('ul')))
{
coll = document.getElementsByTagName('div');
/* ... */
}
When that is coupled with markup that is usable on its own or with
server-side support, any code that executes will either succeed, degrade
to lesser levels (if any were decided upon), or all the way back to
simple markup.
With a scheme such as this, it isn't necessary to provide special
execution paths for obsolete browsers, or those with unusual object
models, if development would be too time-consuming. The user experience
won't be as rich, but it's better than total abandonment.
Quality code should also make maintenance unnecessary with developments
such as new browsers or fixed bugs. If the browser now meets the
requirements, it takes a more demanding code path. If not, it continues
its graceful degradation.
[snip]
> By baselining, I am speaking of identifying the minimum required set of
> browsers/revs that will be supported for any particular application.
In some situations, that might be completely appropriate, but it's far
from the only approach.
[snip]
[Regarding 'hashing']
> If my pointing out teh glaring holes and sweeping generalizations in your
> penchant for precise is t0rlling, then okay. So be it. *shrugs*
If you could tell me where the specification describes hashing, then
you'd have a point, but it doesn't. Again, what mechanisms an
implementation uses isn't an issue here; the /language/ does not work in
terms of hashes, and it was the /language/ that I was commenting on. No
generalisations at all.
[snip]
> Apparently you missed teh bit where I said I generally tend to argue
> against teh use of arrays.
I read that,
> My question to you at teh near beginning (and throughout this thread)
> was, what makes an Object object teh preferred choice, *in this
> case*?
....and I answered that, but clearly not in the direct terms that you
were hoping for.
[snip]
> Unfortunately, I'm not a mind reader, and your vagueness was not
> helping me to grok what that answer was. o_O
The past tense is noted. :)
[snip]
>> new Array(4)
>> new Array('4')
>> new Array(4, 4)
>> new Array(4294967296)
>>
>> These all behave differently.
>
> Yep. You have an array of lenth 4 with index zero through four containing
> an empty string,
Correction: 0 through 3 with no defined elements. Therefore, when the
internal [[Get]] method is called with property names in that range, it
will discover that those properties do not exist and return undefined.
> It seems hardly inconsitent though. Afterall, isn't that how
> teh array constructor is designed to work? o_O
Of course it's inconsistent! Consistent behaviour would have the
constructor work in the same way no matter what the number or type of
arguments. It's /predictable/ of course, but that isn't the same thing.
The point was, as I tried to illustrate with the final 'unknown'
example, is that unless you know what type an argument will be, or what
number of arguments will be parsed, you may or may not get the behaviour
you desire, and at run-time you may not know.
You asked why I would use the array literal, and I answered by saying
that I like uniformity. Anticipating that it might be seen as a rather
arbitrary choice, I sought to explain why I would choose the array
literal: the literal will always create an Array object that contains
the elements in its element list, and that is invariably the behaviour I
want.
>> What would:
>>
>> new Array(x)
>>
>> do?
>
> [...] If x is null (undefined), it would set teh length to one and
> index zero would be empty.
The null and undefined values are very different, and passing either
would not result in an empty element. That is,
new Array(1)
and
new Array(undefined)
are different. Though retrieving index zero will result in undefined in
both cases, it is for different reasons:
var A = new Array(1),
B = new Array(undefined),
p;
for(p in A) {alert('A: ' + p);}
for(p in B) {alert('B: ' + p);}
In the first case, A will have no properties besides those inherited
through the prototype chain. In the second case, B will have a property,
0, with the value undefined, as well as those properties inherited
through the prototype chain.
[snip]
> So basically (and feel free to correct me if I'm wrong), the values I am
> setting in teh pv, saved, mask, & map, are not contained in teh indexed
> lits. Rather, they are /additional/ properties which could just as easily
> be handled in teh Object object (as you earlier noted), bc teh Array object
> does not recognize them as part of its indexed lits (due to teh above
> constraint)?
Essentially, yes.
> In fact, if I understand you correctly, teh Array "only" creates and
> operates on /enumerated/ lits. Period.
That depends on what you're referring to by 'enumerated' lists, and what
you're trying to imply with "only". If you simply mean numbered, then
yes, though there's a little more to it than that.
When you use square bracket notation, the interpreter evaluates the
expression in those brackets, and then converts the result to a string.
This string is the property name for any [[Put]] or [[Get]] operation.
Array instances have a special internal [[Put]] method. Using the
expression I posted previously, this method determines if the property
name is an array index:
ToString | ToUint32 ToString | Is array index
| |
0 '0' | 0 '0' | yes
'7' '7' | 7 '7' | yes
'03' '03' | 3 '3' | no
0x0f '15' | 15 '15' | yes
'five' 'five' | 0 '0' | no
If the name is not an array index, this special [[Put]] method reverts
to normal behaviour: the property is modified (if not read-only) or
created, and the method returns. If it is an array index, and that index
is greater than the length property, the property is created and the
length property is updated. Similarly, if the property name is 'length',
the value is a number, and that number is less than the current value,
the array is truncated. The normal [[Put]] method will treat 'length' as
any other property name.
Furthermore, if you look at the algorithms for all of the
Array.prototype methods, you will see that they all operate in terms of
the length property (usually the first or second step; toString uses
length indirectly), and therefore only on properties that can be
considered to be array indices.
> If this is indeed correct, in conjuction with teh fact that you can
> iterate through teh Ojbect properties (as you earlier noted), then I
> agree. Teh Object object makes more sense, as teh Array object buys
> me absolutely nothing, other than to not only obfuscate what is
> actually occuring, but confuse things as well.
Well, we got there in the end. :)
[snip]
>>> Oh. Okay. So you did not mean to imply they [arrays] behave
>>> erratically, when you wrote this?
>>>
>>> Host properties are implementation specific. In certain
>>> circumstances, simple enumeration works.
>>>
>>> Odd that.
>>
>> Fine misquoting there.
>
> How is it misquoting? [...]
The comment wasn't related to arrays, but to the fact that host-specific
properties are not governed by ECMA-262, and may or may not be
enumerable using a for..in statement. On reflection, 'misquoting' wasn't
the best description - perhaps quoting out of context.
[snip]
> As for teh name attributes, I left those in initially, but removed
> them when firefux was still b0rked (which it still is, btw, teh
> removal of teh hashed line you note later, notwithstanding), [...]
Just so we're clear, exactly how is it still failing? Presumably, either
entering a value into an INPUT element in the symbol table doesn't cause
an update, or the layout is still wrong?
I took a local copy of the 340-Cipher a few days ago, modified the
update function so that it didn't use innerText, and changed a name
attribute to an id. There didn't seem to be any problems there, though I
can't interact with the server, of course. I also assigned explicit
widths to the #menupanel (20em) and #menuitems (712px) rules, and they
display fine as well. Well, more or less: the INPUT elements are a
little too far to the right (in both IE and Fx), so I'd add a little
right padding.
[snip]
> Seriously though, this has been fun *and* informative. I would say that I
> have learned far more about js in this (and the eval convo) than I had ever
> planned (or wanted) to learn. Thanks Michael! :o)
You're welcome. :)
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Navigation:
[Reply to this message]
|