At 9:17 AM -0700 6/29/02, Matt Neuburg wrote:
I would deny that. I always use self if I don't mean a local ("Implicit
Self Called Harmful", don't get me started), and I frequently use a pattern
where I dim myThing locally, calculate and set its value, then pass it up
to self.myThing. It works fine.
I would argue that it's still poor design, for two reasons. First,
you're relying on undocumented behavior -- nowhere (AFAIK) have we
made any explicit claims about whether properties or locals get
precedence when there is a naming conflict. Second, though you may
remember to prefix with "self." when you mean a property (a currently
inefficient technique, though good for clarity), readers of your code
may not be used to it. It'll be clearer if you simply avoid the
conflict.
If it's a bad thing the compiler should flag it.
We don't have compiler warnings, for reasons I can explain if you
like. We do have IDE warnings, though, and these include conflicts
between locals and globals (or two locals -- though this warning is
currently a bit overzealous). Detecting conflicts between a local
and a property turns out to be a bit harder, but I agree it should be
done.
If it's not then autocomplete should work the same way as the compiler.
I agree with this, too. I was only pointing out that, when you trip
over this, renaming your local (or your property) might be a good fix
to consider.
The problem here, you understand, is that autocomplete is too good. A user
will quickly come to rely on it to find out what properties are available.
Yes, I do see your point.
Cheers,
- Joe
--
,------------------------------------------------------------------.
| Joseph J. Strout REAL Software, Inc. |
| joe at realsoftware dot com http://www.realsoftware.com |
`------------------------------------------------------------------'
|