Re: Why does this work?

"Scott M." <s-mar@xxxxxxxxxxxxx> wrote in message news:%23CHdLyVNJHA.3496@xxxxxxxxxxxxxxxxxxxxxxx

"James Hahn" <jhahn@xxxxxxxxx> wrote in message news:%23SalgwNNJHA.2824@xxxxxxxxxxxxxxxxxxxxxxx
The variable 'color' is an instance of the class 'Color', created in the Sub declaration.

No, it is not and that's the source of your confusion. The variable color isn't an "instance" of the class it is simply a parameter variable that shadows the Color type's name. The compiler is able to tell the difference between the two by the context in which the word "color" is used. Not to mention that parameters don't create instances in the first place, they are variables that are either passed a data value or a reference to either a data value or a memory location where an object is stored. Parameters don't instantiate anything.

Tht's just semantics. Let me rephrase it as "The declaration in the Sub is advising the compiler that the object that will be passed to the Sub when it executes will be an instance of the Color class." Did you do as I suggested and ask the compiler to indicate the definition for the variable?

The Color class includes shared readonly properties (the named colors), so the reference within the sub to 'color.AliceBlue' is a reference to the shared member (AliceBlue) using the instance 'color'. That's why the warning appears.

Your close, but not quite correct here. There is no instance of Color. That's the whole point of shared type members, you don't call them from an instance.
You are begging the question. Your comment is reasonable if we assume there is no instance, but the point of the discussion is whether or not the compiler believes that the instance exists. The point is that the compiler reads the original code as attempting to access a shared member of an instance. It's the compiler, not the programmer, that doesn't (won't) do this. That's why the compiler is warning the programmer ('you') that it's not going to do what was coded.

As the OP states, he is NOT getting a warning about this line of code and the reason he's not is because Color.AliceBlue is understood by the compiler as accessing a shared member from a "type", not an instance.

No. OP states that he WAS getting a warning on some machines. His concern was for those cases wher he didn't get a warning.

In OP's case the issue is confused by the fact that a class name has been used as the instance name. You can see what's actually happening by checking the definition of 'color' (the instance, that is, as in 'color.AliceBlue'). The compiler doesn't automatically use the class instead of the instance simply because there's a naming conflict. The compiler has detected that the instance variable is being used to reference the shared member and has provided a warning so that the programmer is aware that the compiler has taken the source code to mean something other than what the programmer wrote. But the code as written is using the instance variable, and that's why the warning has appeared.

Again, you are wrong. There is NO instance being created here and the OP inidcated that he wasn't getting a warning - - only in some cases was a warning showing up. But, we've already answered the question about the warning as being related to difference machine's different compiler warning tolerance settings.

No. Settings have been checked and are not the cause of the problem. The difference is related somehow to the treatment of an instance with a name that matches the class name. The OP will always get a warning if the instance name is different than the class name. The problem was that on SOME machines the warning is not given if the instance name is the same as the class name.

If you want to assert that there is no instance then you have to explain why the compiler issues the warning. I can accept that, in this example, somehow the compiler is deciding that, since the programmer used an instance name that matched (almost) the class name, then they were intending that the reference to the shared variable be through the class, and no warning was deemed necessary. However, I don't believe the compiler is this subtle (and further testing indicates this doesn't happen for other classes). But in any case, the lack of a warning on some machines does not demonstrate that the compiler is treating the variable as a class instead of an instance. And the explicit warning on some machines (and on all machines when the name is different) clearly indicates that the compiler has detected that the programmer is attempting to do something that the compiler will not do - namely reference a shared variable through an instance.

.

Relevant Pages

  • Re: Why does this work?
    ... the reference within the sub to 'color.AliceBlue' is a reference to the ... warning appears. ... compiler as accessing a shared member from a "type", ...
    (microsoft.public.dotnet.languages.vb)
  • Re: any error in the code
    ... the programmer to get this right in the first place. ... Win32 box, because my Linux-based compiler simply isn't interested, no ... even with no options I get "warning: ... implicit declaration of built-in function 'strlen'". ...
    (comp.lang.c)
  • Re: Why does this work?
    ... The variable 'color' is an instance of the class 'Color', created in the Sub declaration. ... The Color class includes shared readonly properties, so the reference within the sub to 'color.AliceBlue' is a reference to the shared member using the instance 'color'. ... The compiler has detected that the instance variable is being used to reference the shared member and has provided a warning so that the programmer is aware that the compiler has taken the source code to mean something other than what the programmer wrote. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Why does this work?
    ... compiler settings. ... But, actually, you code is NOT accessing a shared member through an instance ... On *some* computers this produces the expected warning. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Why INFINITE loop in a thread occupy so much CPU time??
    ... With the attendant warning about the constant expression. ... This is a common programming technique. ... Good programming practice would consist of using the compiler at ... One can write 'bool' in C++ but not C. ...
    (microsoft.public.vc.mfc)