Nickolay Ponomarev wrote:
Richard Cornford wrote:
>It is not necessarily possible to regard any simple example as
good or bad. You have concerned yourself with the explicit
declaration of variables (in a nearby thread), but what is to
stop someone seeing an example of such and making a bad
application of a declaration such as features in the second
example of code in what follows?
Right. As you noticed, I think that using Function constructor
should be avoided, unless using it has benefits.
Which is a reasonable position, but not necessarily better justified
than a position that says that the use of the Function constructor
should only be avoided when its use does no harm. A distinction further
blurred by the realisation that the decision is not made on a single
axis, but instead in a space where many factors influence what may be
regarded as 'benefit' and 'harm', some of which are context related.
This is why I called the examples in the FAQ "bad".
We have seen the specifics: the maintenance headaches and debugging
problems that follow form indirect scripting. Both are valid and
realistic concerns, but more significant with an increase in the size and
complexity of the indirect scripting used. Thus the relative simplicity
of the examples in the FAQ may be argued to mitigate those concerns in
the specific case, and the "bad example" then follows from people seeing
how the Function constructor can be used and extending that to
realisation of what may be done with them, while perhaps not thinking of
undesirable consequences that follow from the elaboration of the example.
It is almost certainly true that if the example in the FAQ were created
today it would be written to assign the results of function expressions
instead of functions constructed with the constructor. However, the
result may still be validly subject to the accusation that it was a "bad
example" because an individual seeing such an example might also see how
the assigning of function expressions could be applied in other contexts
(such as assigned directly to event handlers) and so elaborate the
example into a script that leaked memory in IE browsers (possibly not
noticing at first and incorporating the technique to such an extent that
when the problem was exposed the effort needed to mitigate it had become
a real maintenance headache).
Apparently, you and others who have a say
over what is in the FAQ disagree. Oh well.
The FAQ doesn't really work like that. If there was a sufficient
expression of opinion (from those who's opinions are worth listening to
(so not VK for obvious reasons)) in favour of a change (or a really
compelling argument) then a change would likely follow. (for example, I
have never been in favour of including David Flanagan's book(s) in the
FAQ, yet I added the entry based upon the weight of opinion expressed in
the group.
To the best of my recollection Yep and Evertjan (among some less
significant others) have expresses the opinion that the FAQ should change
from using the Function constructor to using function expressions. You
have added your voice and it probably would not take many more expressing
a similar opinion to qualify as sufficient.
From my point of view it could still go either way, which is shy I am
interested in the possible existence of a compelling argument for one
position or the other. Though I would not like to see the FAQ deprived of
all examples of the use of the Function constructor (this it, I don't
think its use is inherently bad).
>>>We even have browser's like Mozilla/Gecko spitting out
spurious and bogus "warnings"
Any examples? (I know this is off-topic, but since I'm a bit
familiar
with moz and never heard of these, you got me interested)
Given the code:-
if(window.clip boardData){
alert('clipboar d')
}
Mozilla 1.6 (for no other reason than it is the Mozilla version
on this machine) outputs the warning:-
"Warning: reference to undefined property window.clipboar dData"
It seems this no longer happens in newer versions. (1.6 is three
years old.)
It is good to hear that someone has finally come to their senses and
removed that nonsense. It remains depressing to think of all of the
examples of needlessly convoluted code uses in place of simpler
alternatives in order to avoid those "warnings" by people who would (or
could) not see that the warning made no sense in ECMAScript terms and
instead preferred to think of the authors of Mozilla as all-knowing
authorities on the writing of browser scripts (an extremely questionable
position even if the "warning" had not now been rescinded).
>Given the code:-
function testFunc(param) {
var param; // This is a "bad" application of the otherwise "good"
// declaration of local variables.
}
Mozilla outputs the warning:-
"Warning: variable param hides argument"
- and that is an absolute lie. ECMA 262 is very clear about how
such code should be handled (Section 10.1.3) and not only does
the - var param; - not "hide" the - param - formal parameter it
is actually specified as doing nothing
Right, that's how it works, and the warning is indeed a bit
misleading.
"A bit misleading"?
Thanks for mentioning it.
I suppose I should have a go at tracking down the other couple of
spectacularly bad "warnings" that have been brought to my attention over
the years.
<snip>
>>You could save me and yourself some time by only posting
this. You answered my question.
<snip>
I was interested in whether you would present any compelling
arguments for changing the FAQ. You have not.
There are no compelling arguments for changing it if you don't
think that putting code in string literals for no reason is
wrong.
Doesn't that swing on "for no reason". We know that there was a reason
for putting the code in strings in the first place (that it was
originally done at a time when the alternative was non-viable for
cross-browser work). That reason is probably no longer relevant.
I hoped somebody would tell me the reason for *not*
changing it.
I don't think that there is still a reason for not changing it, on the
other hand, I have not seen a positive reason for changing it either.
Apparently
people here just like the Function constructor more.
<snip>
I don't think that is true. I don't think anyone should give in to an
assertion that the use of the Function constructor is always bad without
that being backed up with a pretty solid justification for that position
(something beyond the observation that its use can be objectively bad (on
many fronts) being extended into an absurd blanket injunction against its
use).
An ideal situation exists when individuals find themselves in a position
to assess the merits of any particular technique on an informed basis and
with a consideration of the context in which it may be applied. In such
circumstances there is no need for black and white injunctions, or
declarations of good and bad, as, where valid, those conclusions will
inevitably follow from understanding.
Richard.
