GHUM wrote:
<snip>
>... , "object expected" is an attempt to call a function
where the Identifier for the function did not resolve
into an object, and "'xxx' is undefined" is an attempt
to reference an Identifier where the Identifier has not
been declared. The messages themselves may not be
particularly obvious but their relationships with their
causes is consistent and can be learnt with experience.
That really helped a lot, thank you! Does somebody know
more translations from "Microsoft" to English? Or German?
I am not aware of such a list, but part of my pint was that with a good
understanding of how javascript works the actual messages IE issues are
not actually that obscure. For example, when you call a function that is
not declared (say, miss spell/type the function name) Mozilla/Gecko
browser will say - 'xxx' is not a function - while IE will announce
object expected. But when you discover that the offending code is a
function call, and armed with the understanding that functions are
objects and to call a function, so some referenced must be first
resolved into an object _and_then_ that object must turn out to be
callable (have an internal [[Call]] method) it is not so surprising that
IE kicks out an error message at the point of discovering that the
reference did not resolve as an object, and so the message is couched in
terms of object and not functions.
I can contribute something: From MochiKit:
GetElementsByTa gAndClassName(' tag', 'class', parent='content ')
fails, not because it is implemented in MochiKit AND in the
IE-Javascript, but because of the parent= ... IE seems not to
support named parameters.
Named parameters? Javascript (any ECMA 3 rd Ed (or earlier).
implementation, including JScript <= 5.6) has no notion of named
parameters beyond the formal parameter list declarations (a comma
separated list of zero or more Identifiers) that appear in function
declarations and function expressions.
The - parent='content ' - above is an assignment expression. It assigns a
string value to a scope-resolved property with the name 'parent', and if
no other object on the scope chain has a property called 'parent' it
will be resolved as the 'parent' property of the global/window object.
It is normal for browser environment hosts to provide a 'parent'
property of the global/window object that is used to hold a reference to
the global/window object of the frame containing the (first)
global/window object's frame in a frameset, or the current global/window
if there is no frameset (or IRAMEs in the parent). This is why IE is
complaining as it does not allow this value to be re-assigned (and it is
optionally allowed to do that by specification).
Assignment expressions are allowed in the arguments list used in a
(function) call expression, indeed the (optional) ArgumentsList is
formally defined as a comma separated list of one or more
AssignmentExpre ssions, though the AssignmentExpre ssion is a category of
expressions that goes well beyond actual assignment operations. In a
call expression the AssignmentExpre ssions are evaluated and it is the
result of that evaluation is passed to the function call as its
argument. An assignment operation evaluates as the value assigned so -
parent='content ' evaluates as the string 'content', and the assignment
of the value to the 'parent' property of some object on the scope chain
is a side effect (desirable or otherwise).
If the notion here is that the Identifier - parent - can then be used
within the function called to refer to the argument then in may cases it
can, but the mechanism then has nothing to do with the arguments to the
function call. Instead the side effect of assigning the value to what is
in effect a global variable is mirrored by the fact that the use of an
undeclared (as a formal parameter, inner function declaration or local
variable name) Identifier will also result in resolution against the
scope chain with a high probability of the result being a reference to
the same global variable as the value had been written to during the
evaluation of the arguments to the function call. So once again a
misconception about how javascript works can avoid being exposed because
the code that employs it seems to 'work', at least up to the point where
it doesn't work.
It worries me that you have described this as 'named parameters' and I
wonder where you got that idea. I hope that the alarm bells are now
ringing and you can now see that you have identified a source of
information that is not reliable (is fundamentally mistaken about the
nature of javascript). You have not explained what this 'MochiKit' is,
or what relevance it has, but if it is the source of the 'named
parameters' suggestion you need to be questioning the competence of the
people responsible.
<snip>
But I still feel this is so 1980ish to find the offending
line via inserting blanks;
I tend to be pragmatic, if something tells me what I need to know in
return for (literally in most cases) a few seconds work then I am not
going to worry that it doesn't seem so sophisticated.
especially knowing that Microsoft is one of the leading
suppliers of Software Development Tools. It's a shame,
definitely.
Remember the role of marketing in business. It is not about finding out
what people what, it is about finding out how little can be got away
with, because no business can make a profit by giving people what the
want. Microsoft is a very successful business.
Richard.
