Static Abstract methods? Why not?

Re: Static Abstract methods? Why not?

Mike Ruane-Torr wrote:[color=blue]
> Why can't I have a static abstract method in C#?[/color]

Static members cannot be virtual. That makes sense when you think about it.
I've never heard of the concept of static polymorphism.

<I'm learning new stuff all the time>

--
There are 10 kinds of people. Those who understand binary and those who
don't.


(Pull the pin to reply)

Re: Static Abstract methods? Why not?

Mike Ruane-Torr <mike.ruane-torr@USE_EVENS_ ixwiflaoyn.net> wrote:[color=blue]
> Why can't I have a static abstract method in C#?
>
> My intention is to have a class-level method that returns a string to
> supply information about inherited classes, and it is natural to make this
> static so that I don't need an instance in order to call it. However,
> because my class model is using a common base class, I need to make it
> abstract too, so that inherited classes are forced to implement it.[/color]

You might like to think about how you would call the method, if you
could implement it... if you don't have an instance, how would the
compiler or runtime know which implementation to call?
[color=blue]
> Am I doing something that can be done another way, or considered 'ugly' in
> OOD? Or is C# being inconsiderate?[/color]

See my response to the post from phoenix entitled "interface and static
(abstract base class?)" from a few days ago for more information.

--
Jon Skeet - <skeet@pobox.co m>

If replying to the group, please do not mail me too

Re: Static Abstract methods? Why not?

> Why can't I have a static abstract method in C#?

abstract methods are implicitly virtual, virtual methods require an
instance.

You can have a static method in an abstract class, it just cannot be static
abstract (or abstract static).
[color=blue]
> My intention is to have a class-level method that returns a string to
> supply information about inherited classes, and it is natural to make this
> static so that I don't need an instance in order to call it. However,
> because my class model is using a common base class, I need to make it
> abstract too, so that inherited classes are forced to implement it.[/color]

Do you have an example of what you're trying to do? If a static abstract
method were available what you're suggesting would be impossible anyway.
Perhaps there is another way of doing what you want.

If you're expecting derived classes to implement it, you need an instance
because without an instance it wouldn't know which one you wanted to call.

n!

Re: Static Abstract methods? Why not?

Frank Oquendo <franko@acadxpi n.com> wrote:[color=blue]
> Mike Ruane-Torr wrote:[color=green]
> > Why can't I have a static abstract method in C#?[/color]
>
> Static members cannot be virtual. That makes sense when you think about it.
> I've never heard of the concept of static polymorphism.
>
> <I'm learning new stuff all the time>[/color]

I *think* Smalltalk effectively has it - but I wouldn't like to say for
sure, not knowing ST myself.

--
Jon Skeet - <skeet@pobox.co m>

If replying to the group, please do not mail me too

Re: Static Abstract methods? Why not?

On Fri, 13 Feb 2004 15:48:17 -0000, Jon Skeet [C# MVP] <skeet@pobox.co m>
wrote:
[color=blue]
> Mike Ruane-Torr <mike.ruane-torr@USE_EVENS_ ixwiflaoyn.net> wrote:[color=green]
>> Why can't I have a static abstract method in C#?
>>
>> My intention is to have a class-level method that returns a string to
>> supply information about inherited classes, and it is natural to make
>> this
>> static so that I don't need an instance in order to call it. However,
>> because my class model is using a common base class, I need to make it
>> abstract too, so that inherited classes are forced to implement it.[/color]
>
> You might like to think about how you would call the method, if you
> could implement it... if you don't have an instance, how would the
> compiler or runtime know which implementation to call?
>[color=green]
>> Am I doing something that can be done another way, or considered 'ugly'
>> in
>> OOD? Or is C# being inconsiderate?[/color]
>
> See my response to the post from phoenix entitled "interface and static
> (abstract base class?)" from a few days ago for more information.
>[/color]
OK, I just read it. So basically, I can't do it because it isn't allowed,
but you accept that it would be nice to have the feature, if I read your
response correctly.

It is a little irksome, because now I will have to make non-static,
non-virtual methods and override them with 'new' in the derived classes -
however, I will also need to implement the methods in the base class,
which doesn't make sense in the context of my design model. Perhaps I
shall just make them return a string that says ".Net needs a new feature!"
:)


--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Re: Static Abstract methods? Why not?

Mike Ruane-Torr <mike.ruane-torr@USE_EVENS_ ixwiflaoyn.net> wrote:[color=blue][color=green]
> > See my response to the post from phoenix entitled "interface and static
> > (abstract base class?)" from a few days ago for more information.[/color]
>
> OK, I just read it. So basically, I can't do it because it isn't allowed,
> but you accept that it would be nice to have the feature, if I read your
> response correctly.[/color]

Sort of. It's not just a case of the compiler disallowing it just to be
annoying - it's because if the compiler *did* allow it without further
language changes, it would be pretty useless. (I suspect it would also
require CLR changes, although I'm not sure.)
[color=blue]
> It is a little irksome, because now I will have to make non-static,
> non-virtual methods and override them with 'new' in the derived classes -
> however, I will also need to implement the methods in the base class,
> which doesn't make sense in the context of my design model. Perhaps I
> shall just make them return a string that says ".Net needs a new feature!"
> :)[/color]

Instead of that, you could implement it with by convention, and then
invoke the method by reflection. You'd also want to write a tool to
make sure that all the appropriate types *did* actually implement the
method, probably.

--
Jon Skeet - <skeet@pobox.co m>

If replying to the group, please do not mail me too

Re: Static Abstract methods? Why not?

Mike,

To call a static method, you need to scope it by the class name e.g.
SomeClass.SomeM ethod. So, effectively, to call a static method you already
know what class your calling it on. The fact that you know what class your
calling means that by definition you don't need polymorphism i.e. you don't
need abstract or virtual.

Am I missing something?

-Jason

"Mike Ruane-Torr" <mike.ruane-torr@USE_EVENS_ ixwiflaoyn.net> wrote in
message news:opr3bf32gs 4jyps0@msnews.m icrosoft.com...[color=blue]
> On Fri, 13 Feb 2004 15:48:17 -0000, Jon Skeet [C# MVP] <skeet@pobox.co m>
> wrote:
>[color=green]
> > Mike Ruane-Torr <mike.ruane-torr@USE_EVENS_ ixwiflaoyn.net> wrote:[color=darkred]
> >> Why can't I have a static abstract method in C#?
> >>
> >> My intention is to have a class-level method that returns a string to
> >> supply information about inherited classes, and it is natural to make
> >> this
> >> static so that I don't need an instance in order to call it. However,
> >> because my class model is using a common base class, I need to make it
> >> abstract too, so that inherited classes are forced to implement it.[/color]
> >
> > You might like to think about how you would call the method, if you
> > could implement it... if you don't have an instance, how would the
> > compiler or runtime know which implementation to call?
> >[color=darkred]
> >> Am I doing something that can be done another way, or considered 'ugly'
> >> in
> >> OOD? Or is C# being inconsiderate?[/color]
> >
> > See my response to the post from phoenix entitled "interface and static
> > (abstract base class?)" from a few days ago for more information.
> >[/color]
> OK, I just read it. So basically, I can't do it because it isn't allowed,
> but you accept that it would be nice to have the feature, if I read your
> response correctly.
>
> It is a little irksome, because now I will have to make non-static,
> non-virtual methods and override them with 'new' in the derived classes -
> however, I will also need to implement the methods in the base class,
> which doesn't make sense in the context of my design model. Perhaps I
> shall just make them return a string that says ".Net needs a new feature!"
> :)
>
>
> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/[/color]

Re: Static Abstract methods? Why not?

Mike,
For arguments sake lets look at it practically on how you'd see
it being used

abstract class A {
public static abstract string functionA();
}

class B : A {
public static string functionA() {
return "B";
}
}

Now if your're going to be calling it...
would'nt you be calling it

B.functionA();

at which point wouldnt you already be knowing what type it is? because
you're calling the function explicitly *B.*. Let me know if I din't
understand your requirement, hope that helps

Mike Ruane-Torr wrote:
[color=blue]
> Why can't I have a static abstract method in C#?
>
> My intention is to have a class-level method that returns a string to
> supply information about inherited classes, and it is natural to make
> this static so that I don't need an instance in order to call it.
> However, because my class model is using a common base class, I need to
> make it abstract too, so that inherited classes are forced to implement it.
>
> Am I doing something that can be done another way, or considered 'ugly'
> in OOD? Or is C# being inconsiderate?
>[/color]

--
Regards,
Dilip Krishnan
MCAD, MCSD.net
dilipdotnet at apdiya dot com

Re: Static Abstract methods? Why not?

Mailing Lists <ml010241@berke a.com> wrote:[color=blue]
> To call a static method, you need to scope it by the class name e.g.
> SomeClass.SomeM ethod. So, effectively, to call a static method you already
> know what class your calling it on. The fact that you know what class your
> calling means that by definition you don't need polymorphism i.e. you don't
> need abstract or virtual.
>
> Am I missing something?[/color]

Yes - the extra bit of functionality I was talking about. You often
have the concrete type as a Type object, but not otherwise.
Alternatively, you may have an instance of the concrete type, but not
know in advance what it is. There could be syntax such that you could
call, say:

ISomeInterface< typeOfPlugin>.S omeMethod();

or

ISomeInterface< instance>.SomeM ethod();

(syntax made up on the spot).

The main place (IME) where this would be useful would be for
constructors. If everything which implemented the interface had to
provide a certain constructor, you could do something like:

ISomeInterface instance = new ISomeInterface< typeOfPlugin>(p arameters);

That would be much more type-safe (if appropriately implemented in the
compiler and specs) than the current way of doing things, which is by
reflection with no real safety.

--
Jon Skeet - <skeet@pobox.co m>

If replying to the group, please do not mail me too

Re: Static Abstract methods? Why not?

Jon,
I din't quite understand your comments.

Jon Skeet [C# MVP] wrote:
[color=blue]
> Mailing Lists <ml010241@berke a.com> wrote:
>[color=green]
>>To call a static method, you need to scope it by the class name e.g.
>>SomeClass.Som eMethod. So, effectively, to call a static method you already
>>know what class your calling it on. The fact that you know what class your
>>calling means that by definition you don't need polymorphism i.e. you don't
>>need abstract or virtual.
>>
>>Am I missing something?[/color]
>
>
> Yes - the extra bit of functionality I was talking about. You often
> have the concrete type as a Type object, but not otherwise.[/color]

Every class abstract or otherwise has a type and you could get it by
using the typeof operator. Is this what you meant?
[color=blue]
> Alternatively, you may have an instance of the concrete type, but not
> know in advance what it is. There could be syntax such that you could
> call, say:
>[/color]
Why wouldnt you know what type it is? from the type object you could get
all this information
[color=blue]
> ISomeInterface< typeOfPlugin>.S omeMethod();
>
> or
>
> ISomeInterface< instance>.SomeM ethod();
>
> (syntax made up on the spot).
>
> The main place (IME) where this would be useful would be for
> constructors. If everything which implemented the interface had to
> provide a certain constructor, you could do something like:
>
> ISomeInterface instance = new ISomeInterface< typeOfPlugin>(p arameters);
>
> That would be much more type-safe (if appropriately implemented in the
> compiler and specs) than the current way of doing things, which is by
> reflection with no real safety.
>[/color]

--
Regards,
Dilip Krishnan
MCAD, MCSD.net
dilipdotnet at apdiya dot com

Re: Static Abstract methods? Why not?

The first case assumes you have a System.Type object, which means you can
instantiate the type it describes--and call methods on it--if you desire.
The second case starts with you holding an instance which can be cast to the
interface you're interested in using. I still don't get it....

Question: Assume a class 'A' with a static abstract method m(). Now, you've
also got two other classes, 'B' and 'C' which inherit from 'A' and override
and implement m() as required. When my code calls A.m(), which of these two
(B.m() or C.m()) should execute? Isn't this what the original post was
aiming for with the "no this pointer" requirement? Again, I could be
missing something, but this seems ambiguous/unresolvable to me.

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a9716 07273b6baa98a12 d@msnews.micros oft.com...[color=blue]
> Mailing Lists <ml010241@berke a.com> wrote:[color=green]
> > To call a static method, you need to scope it by the class name e.g.
> > SomeClass.SomeM ethod. So, effectively, to call a static method you[/color][/color]
already[color=blue][color=green]
> > know what class your calling it on. The fact that you know what class[/color][/color]
your[color=blue][color=green]
> > calling means that by definition you don't need polymorphism i.e. you[/color][/color]
don't[color=blue][color=green]
> > need abstract or virtual.
> >
> > Am I missing something?[/color]
>
> Yes - the extra bit of functionality I was talking about. You often
> have the concrete type as a Type object, but not otherwise.
> Alternatively, you may have an instance of the concrete type, but not
> know in advance what it is. There could be syntax such that you could
> call, say:
>
> ISomeInterface< typeOfPlugin>.S omeMethod();
>
> or
>
> ISomeInterface< instance>.SomeM ethod();
>
> (syntax made up on the spot).
>
> The main place (IME) where this would be useful would be for
> constructors. If everything which implemented the interface had to
> provide a certain constructor, you could do something like:
>
> ISomeInterface instance = new ISomeInterface< typeOfPlugin>(p arameters);
>
> That would be much more type-safe (if appropriately implemented in the
> compiler and specs) than the current way of doing things, which is by
> reflection with no real safety.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

Re: Static Abstract methods? Why not?

Dilip Krishnan <dilipdotnet..N OSPAM..@apdiya. com> wrote:[color=blue][color=green]
> > Yes - the extra bit of functionality I was talking about. You often
> > have the concrete type as a Type object, but not otherwise.[/color]
>
> Every class abstract or otherwise has a type and you could get it by
> using the typeof operator. Is this what you meant?[/color]

You may not know the type name in advance though - the type may not
even have been written when you write the code! (Think of a plugin
situation.)
[color=blue][color=green]
> > Alternatively, you may have an instance of the concrete type, but not
> > know in advance what it is. There could be syntax such that you could
> > call, say:[/color]
>
> Why wouldnt you know what type it is? from the type object you could get
> all this information[/color]

You could certainly call GetType() on the object, yes. I'd have to see
lots of use cases before deciding whether or not it was worth having it
as extra syntax, or whether it should only work on the type itself.

--
Jon Skeet - <skeet@pobox.co m>

If replying to the group, please do not mail me too

Re: Static Abstract methods? Why not?

Mailing Lists <ml010241@berke a.com> wrote:[color=blue]
> The first case assumes you have a System.Type object, which means you can
> instantiate the type it describes--and call methods on it--if you desire.[/color]

How, exactly, without using reflection which diminishes type safety?
Without any extra facilities, you can't guarantee that a type has a
constructor with specific parameters.

Plugins are typical here - you can't guarantee what constructors will
be there, nor can you specify (in a compiler-checkable way) what
constructors the calling code will expect.
[color=blue]
> The second case starts with you holding an instance which can be cast to the
> interface you're interested in using. I still don't get it....
>
> Question: Assume a class 'A' with a static abstract method m().[/color]

Yup.
[color=blue]
> Now, you've
> also got two other classes, 'B' and 'C' which inherit from 'A' and override
> and implement m() as required. When my code calls A.m(), which of these two
> (B.m() or C.m()) should execute? Isn't this what the original post was
> aiming for with the "no this pointer" requirement? Again, I could be
> missing something, but this seems ambiguous/unresolvable to me.[/color]

That's why you need the extra syntax which specifies the actual type to
call the method on.

--
Jon Skeet - <skeet@pobox.co m>

If replying to the group, please do not mail me too

Re: Static Abstract methods? Why not?


"Frank Oquendo" <franko@acadxpi n.com> wrote in message
news:uZIlHgk8DH A.360@TK2MSFTNG P12.phx.gbl...[color=blue]
> Mike Ruane-Torr wrote:[color=green]
> > Why can't I have a static abstract method in C#?[/color]
>
> Static members cannot be virtual. That makes sense when you think about[/color]
it.[color=blue]
> I've never heard of the concept of static polymorphism.
>[/color]

Templates (or generics in C# parlance) are actually pretty close to what you
could call static polymorphism. Consider this imaginary syntax:

interface ISingleton<T>
{
static T Instance();
}

class X : ISingleton<X>
{
static X x_ = new X();
static X Instance() { return x_; }
}

Makes perfect sense eh?

Sami