On Fri, 28 Jun 2002 12:24:58 -0700, "Joseph J. Strout"
<joe at realsoftware dot com> said:
>At 11:19 AM -0700 6/28/02, Matt Neuburg wrote:
>
>>Suppose you have a property d as database and a local variable d as
>>MySQLDatabase. If you type "d." to get autocomplete, "port" is not among
>>the choices because autocomplete doesn't understand - as the compiler does
>>- that d is the local d. m.
>
>But of course, creating such a variable-name conflict is a bad idea
>for other reasons, too.
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. If it's a bad thing the compiler should
flag it. If it's not then autocomplete should work the same way as the
compiler.
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.
In the case of a MySQLDatabase there is nothing in the online docs, so the
*only* way to find out that there is a port property is from the
autocomplete. But in the situation above, I was not finding this out,
because "d." was being interpreted as Database, which has no port property.
Therefore I wasn't able to connect. I lost several hours futzing with this.
In other words, since autocomplete is *the* mechanism by which one learns
about plug-in-based properties such as MySQLDatabase, the better it works,
the better. :-) m.
--
matt neuburg, phd = matt at tidbits dot com, http://www.tidbits.com/matt
pantes anthropoi tou eidenai oregontai phusei
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
|