I thought this wasn't allowed in C# - invoking static members from a subclass

[Larry Lard]

Today I discovered that a syntax that I thought was forbidden in C# but
allowed in VB.NET (and I _don't like_ that it's allowed in VB.NET) is
actually allowed in C#. Which confused me. The syntax in question is
referring to static members of a class *from a subclass*.

(Now, I know for sure there's a similar difference, in that VB.NET
allows/ed you to invoke static members from an instance member, whereas
C# has always required you to give the class name. This is different)

My usual example for this has always been

.... = Bitmap.FromFile(FileName)

I hate seeing this (or things like it) in VB.NET because it's
completely misleading. FromFile is a method of *Image* and it returns
an *Image*, but when you _read_ 'Bitmap.FromFile' you _think_ - oh
that's going to give me a bitmap from a file. hang on, why am I getting
an assignment error?'. Another problem is this: open your MSDN Library,
go to the Index, and type Bitmap.Fromf ... wait a minute ... confusion
results!

But it seems C# is perfectly happy with this (not even a warning)?! So
where did I get the idea it wasn't? And why is this allowed?

 

[Guest]

I agree it can be confusing, but if you are aware that FromFile is
implemented in the abstract Image class, and not in the derived Bitmap class
it's not that big of a deal.

Bitmap myPic = Bitmap.FromFile(@"C:\MyBitmap.bmp") as Bitmap;

You do get a compile error is do you do not convert the returning Image
instance into a bitmap. Take out the "as Bitmap" part and you'll get a
compile error. That's warning enough I think.

Will do the trick.

 

[Bruce Wood]

I find this notation confusing as well, and I can't see any reason for
including it in the language.

Does anyone know the reasoning behind this one?

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

My usual example for this has always been

... = Bitmap.FromFile(FileName)

I hate seeing this (or things like it) in VB.NET because it's
completely misleading. FromFile is a method of *Image* and it returns
an *Image*, but when you _read_ 'Bitmap.FromFile' you _think_ - oh
that's going to give me a bitmap from a file. hang on, why am I getting
an assignment error?'. Another problem is this: open your MSDN Library,
go to the Index, and type Bitmap.Fromf ... wait a minute ... confusion
results!

This particular case is confusing, the first question is why a base abstract
class return an instance of a derived class?

Of course as FromFile cannot be virtual (as it's static) you cannot let the
derived class implement it.

IMO FromFile should had been declared in Bitmap and not in Image.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I find this notation confusing as well, and I can't see any reason for
including it in the language.

Does anyone know the reasoning behind this one?

The only reason I can think of is to allow the class (and its descendand)
to call the static method without a reference to the class:

class A{
static void M(){}

void aMethid(){ M(); } //allow this



Which I also find confusing, IMO static members should always been invoked
from the type that defined them

 

[Bruce Wood]

Of course as FromFile cannot be virtual (as it's static) you cannot let the derived class implement it.

At first blush this doesn't make any sense, but sure enough, the
compiler doesn't like this:

public class A { public static void foo() { } }

public class B : A { public static void foo() { } }

Now, my little brain says that there should be no problem here: static
members are not inherited, so I've just declared two distinct methods,
A.foo() and B.foo(). However, sure enough, the compiler complains that
B.foo() required the keyword "new" because it "hides inherited member
A.foo()". Now, is that nuts, or what? Static members aren't inherited,
but they are... sort of.

Jon Skeet pointed this out to me a couple of months ago. It still
doesn't make a lick of sense to me.

Does anyone know the rationale for including this oddity in the way
that .NET handles inheritance? I imagine it was deliberate....

 

[Nick Hounsome]

Hi,



The only reason I can think of is to allow the class (and its descendand)
to call the static method without a reference to the class:

class A{
static void M(){}

void aMethid(){ M(); } //allow this

Which I also find confusing, IMO static members should always been invoked
from the type that defined them

It is consistent with non-static methods and allows static methods to be
moved to a base class without breaking code or requiring you to know the
ancestry.

 

[Ignacio Machin \( .NET/ C# MVP \)]

HI,

It is consistent with non-static methods and allows static methods to be
moved to a base class without breaking code or requiring you to know the
ancestry.

I'm not very sure it's a good thing , after all thery are not the same as
instance method.

It does break the code if you call them from outside a derived class.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Jon Skeet pointed this out to me a couple of months ago. It still
doesn't make a lick of sense to me.

Do you have that post around? or a link to it . I would love to read it