On Fri, Oct 24, 2008 at 12:40 AM, Douglas Crockford
> I don't want to modify JSLint to satisfy a single, unnecessary,
> dubious use. I recommend that you change your variable name.
I agree. But you misunderstand my complaint.
It is trivial to change my program to work with JSLint, and indeed I
have already done so.
However, I believe that calling hasOwnProperty in the form
obj.hasOwnProperty(p) is a bad practice. The reason it is bad is that
naive, lazy or tired developers will assume that obj is a generic
container which can contain any key/value pair, whereas in fact it is
unable to safely contain the key "hasOwnProperty". I have seen this
exact problem several times in the wild.
JSLint itself does not make this assumption, so this is not really a
bug. But I believe that bad practices are best avoided even when the
developer knows they are safe -- unless there is no alternative.
My complaint is that there is a trivial, safe alternative to the bad
practice and that JSLint does not use it. That is all.
> And if
> you are trying to implement hasOwnProperty, I think you intended
You're right. I was retyping from memory -- it's a typo and not
present in the original code, honest :).
> But I don't think it works for
> mischievous objects that have altered or inherited constructor
I agree, it's impossible to correctly reimplement hasOwnProperty on
implementations where it is not present, which is a shame. That's why
my snippet defers to the built-in hasOwnProperty whenever possible.
That said, you have raised the rather important point that, on
platforms with no hasOwnProperty, I'm exchanging one problem for
another in that now objects which are assumed to be generic containers
will be able to contain members named "hasOwnProperty", but unable to
contain members named "constructor". I have no idea how I missed that
-- thanks for the observation.
attempt at reimplementing hasOwnProperty is very much irrelevant to
the point that I was trying to raise :).