Why does this work?

  • Thread starter Thread starter Bob Altman
  • Start date Start date
James Hahn said:
You assert that this behaviour is 'correct' without any supporting
argument (other than that it seems sensible to you).

Perhaps you would like to refer us all to your MS reference for this
single exception to the standard name resolution rules in VB. Or some
other case where VB similarly ignores the standard rules without any
warning.
Click to expand...

I'm sorry, did you provide a MS reference to the "standard name resolutions
rules for VB .NET"? It seems to me that you simply made an assertion of the
way naming works without any reference to support your statement as well.
 
James Hahn said:
No. The difference between what the code is doing and what the compiler is
doing is the reason for the warning.
Click to expand...

Exactly. This is especially important if the shared member is accessed for
an object returned by an expression, which may change the application's
state, but the expression gets removed by the compiler:

\\\
Dim c As Color = Foo.DoSomething().AliceBlue
///
 
This note at the bottom of the second reference confuses me regarding the
color instance versus color class name:

Note An implication of this resolution process is that type members do not
shadow namespaces or types when resolving namespace or type names.
 
Bob Altman said:
I'll be at PDC (the Microsoft Professional Developer's Conference) this
week. I'm going to see if I can get any insight from any of the MS
developers hanging out in the lounge.

Bob
Click to expand...


Getting back to the original question, I talked to a VB compiler guy at PDC
(I don't remember his name, but I know I've read his blog) and he says that
the lack of a warning in this case is a bug that should be reported to MS
Connect, which I will do.

Bob (the now infamous OP)
 
Back
Top