What is the rationale behind the decision not to allow abstract static class
members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems like
it would be useful. In fact, there's a place in my code that I could make
good use of it. So why not?
Chris
Nov 15 '05
33  3351 
"Jonathan Malek" <jm*****@hotmai l.com> wrote in message
news:e4******** *************** ***@posting.goo gle.com... I traced through the responses to the original question, and while I
might have missed something, I feel Chris Capel's question was never
really answered. There were responses about how to do what Chris
wants to do differently, responses that argued the idea, even a nod to
contracts--which I thought missed the whole point.
In the example given, a contract has already been established--in the
form of an abstract class.
I have my own design issue, which brought me to this group in the
first place. I am working on a large number of domain and data mapper
pattern objects. Some of my mappers can handle more than one domain
object, because the domain objects are subclassed.
In order to use a mapper registry (factory) to produce them, I decided
to have each mapper track its mapped types:
public abstract class BaseDataMapper
{
public abstract Type[] MappedTypes{ get ; }
...
}
I think it is reasonable that the author of a mapper should decide
which objects that mapper can map into persistent storage:
public class NamedObjectMapp er : BaseDataMapper
{
public override Type[] MappedTypes
{
get{ return new Type[]{ typeof( ServiceType ), typeof(
UnitType ) } ; )
}
}
Now, during registration of the above mapper type in a factory, I need
some way of registering the supported types--from:
mapperRegistry. GetInstanceFor( ServiceType )
I expect the factory to produce the exact mapper I need. Unless the
property described above is also abstract, I cannot do this without
creating an instance of the mapper during registration. Five mappers?
No big deal. Four hundred mappers in a service layer? No way I want
to create an instance of all of those during registration. Not in an
environment where new domain objects and mappers can be added at
runtime, and their types registered.
And this is the thing: attributes? Come on. The issue here is to
force the mapper author to comply with the contract.
So--why not abstract statics?
Because they are messy, if you read everything posted there were a number of
arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature that
REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just that
purpose(among others, of course). I do however think that a contract that
can handle required attributes should exist, that is a very different matter
entirely.
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:<#h******* *******@tk2msft ngp13.phx.gbl>. .. What is the rationale behind the decision not to allow abstract static
class members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems
like it would be useful. In fact, there's a place in my code that I could
make good use of it. So why not?
Chris
Daniel,
Correct me if I am wrong, but there is no polymorphic way to access static methods in C# because C# doesn't support virtual static methods. Other languages do (Delphi, for one). In other words, the most important argument for not having abstract statics is that C# doesn't support them. So, I figure I am missing something.
I have read quite a bit on this topic in other lists (the comp.std.c++ list had what seems like a semi-annual celebration on the issue for several years), trying to understand what the issue is. I suppose I don't quite see the messy aspect of it all. Everyone raises the same issue--"virtual static?? Why ever would you want to do such a thing? Oh I see--well, you know, you could do that this way, or that way..." That's not really an answer. It can be done, it solves a particular design problem (I've written one up below that I feel can only be solved this way--or, as you mention, with contract-enforced attributes), and other languages have shown that.
So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that prohibits such a thing? Better question--is it possible to introduce CTS-compliant virtual statics? I suppose if the answer to that is no, then it is pointless wondering why C# doesn't support them. "Jonathan Malek" <jm*****@hotmai l.com> wrote in message
news:e4******** *************** ***@posting.goo gle.com... I traced through the responses to the original question, and while I
might have missed something, I feel Chris Capel's question was never
really answered. There were responses about how to do what Chris
wants to do differently, responses that argued the idea, even a nod to
contracts--which I thought missed the whole point.
In the example given, a contract has already been established--in the
form of an abstract class.
I have my own design issue, which brought me to this group in the
first place. I am working on a large number of domain and data mapper
pattern objects. Some of my mappers can handle more than one domain
object, because the domain objects are subclassed.
In order to use a mapper registry (factory) to produce them, I decided
to have each mapper track its mapped types:
public abstract class BaseDataMapper
{
public abstract Type[] MappedTypes{ get ; }
...
}
I think it is reasonable that the author of a mapper should decide
which objects that mapper can map into persistent storage:
public class NamedObjectMapp er : BaseDataMapper
{
public override Type[] MappedTypes
{
get{ return new Type[]{ typeof( ServiceType ), typeof(
UnitType ) } ; )
}
}
Now, during registration of the above mapper type in a factory, I need
some way of registering the supported types--from:
mapperRegistry. GetInstanceFor( ServiceType )
I expect the factory to produce the exact mapper I need. Unless the
property described above is also abstract, I cannot do this without
creating an instance of the mapper during registration. Five mappers?
No big deal. Four hundred mappers in a service layer? No way I want
to create an instance of all of those during registration. Not in an
environment where new domain objects and mappers can be added at
runtime, and their types registered.
And this is the thing: attributes? Come on. The issue here is to
force the mapper author to comply with the contract.
So--why not abstract statics?
Because they are messy, if you read everything posted there were a number of
arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature that
REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just that
purpose(among others, of course). I do however think that a contract that
can handle required attributes should exist, that is a very different matter
entirely.
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:<#h******* *******@tk2msft ngp13.phx.gbl>. .. What is the rationale behind the decision not to allow abstract static class members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems like it would be useful. In fact, there's a place in my code that I could make good use of it. So why not?
Chris
Daniel,
Correct me if I am wrong, but there is no polymorphic way to access static methods in C# because C# doesn't support virtual static methods. Other languages do (Delphi, for one). In other words, the most important argument for not having abstract statics is that C# doesn't support them. So, I figure I am missing something.
I have read quite a bit on this topic in other lists (the comp.std.c++ list had what seems like a semi-annual celebration on the issue for several years), trying to understand what the issue is. I suppose I don't quite see the messy aspect of it all. Everyone raises the same issue--"virtual static?? Why ever would you want to do such a thing? Oh I see--well, you know, you could do that this way, or that way..." That's not really an answer. It can be done, it solves a particular design problem (I've written one up below that I feel can only be solved this way--or, as you mention, with contract-enforced attributes), and other languages have shown that.
So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that prohibits such a thing? Better question--is it possible to introduce CTS-compliant virtual statics? I suppose if the answer to that is no, then it is pointless wondering why C# doesn't support them. "Jonathan Malek" <jm*****@hotmai l.com> wrote in message
news:e4******** *************** ***@posting.goo gle.com... I traced through the responses to the original question, and while I
might have missed something, I feel Chris Capel's question was never
really answered. There were responses about how to do what Chris
wants to do differently, responses that argued the idea, even a nod to
contracts--which I thought missed the whole point.
In the example given, a contract has already been established--in the
form of an abstract class.
I have my own design issue, which brought me to this group in the
first place. I am working on a large number of domain and data mapper
pattern objects. Some of my mappers can handle more than one domain
object, because the domain objects are subclassed.
In order to use a mapper registry (factory) to produce them, I decided
to have each mapper track its mapped types:
public abstract class BaseDataMapper
{
public abstract Type[] MappedTypes{ get ; }
...
}
I think it is reasonable that the author of a mapper should decide
which objects that mapper can map into persistent storage:
public class NamedObjectMapp er : BaseDataMapper
{
public override Type[] MappedTypes
{
get{ return new Type[]{ typeof( ServiceType ), typeof(
UnitType ) } ; )
}
}
Now, during registration of the above mapper type in a factory, I need
some way of registering the supported types--from:
mapperRegistry. GetInstanceFor( ServiceType )
I expect the factory to produce the exact mapper I need. Unless the
property described above is also abstract, I cannot do this without
creating an instance of the mapper during registration. Five mappers?
No big deal. Four hundred mappers in a service layer? No way I want
to create an instance of all of those during registration. Not in an
environment where new domain objects and mappers can be added at
runtime, and their types registered.
And this is the thing: attributes? Come on. The issue here is to
force the mapper author to comply with the contract.
So--why not abstract statics?
Because they are messy, if you read everything posted there were a number of
arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature that
REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just that
purpose(among others, of course). I do however think that a contract that
can handle required attributes should exist, that is a very different matter
entirely.
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:<#h******* *******@tk2msft ngp13.phx.gbl>. .. What is the rationale behind the decision not to allow abstract static class members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems like it would be useful. In fact, there's a place in my code that I could make good use of it. So why not?
Chris
"Jonathan Malek" <no************ *@hotmail.com> wrote in message
news:eB******** ******@TK2MSFTN GP09.phx.gbl... Daniel,
Correct me if I am wrong, but there is no polymorphic way to access static
methods in C# because C# doesn't support virtual static methods. Other
languages do (Delphi, for one). In other words, the most important argument
for not having abstract statics is that C# doesn't support them. So, I
figure I am missing something. I have read quite a bit on this topic in other lists (the comp.std.c++
list had what seems like a semi-annual celebration on the issue for several
years), trying to understand what the issue is. I suppose I don't quite see
the messy aspect of it all. Everyone raises the same issue--"virtual
static?? Why ever would you want to do such a thing? Oh I see--well, you
know, you could do that this way, or that way..." That's not really an
answer. It can be done, it solves a particular design problem (I've written
one up below that I feel can only be solved this way--or, as you mention,
with contract-enforced attributes), and other languages have shown that. So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that
prohibits such a thing? Better question--is it possible to introduce
CTS-compliant virtual statics? I suppose if the answer to that is no, then
it is pointless wondering why C# doesn't support them.
Well, the primary problem is in cases like this, assume Base has a virtual
static called StaticMethod and Derived is derived from Base.
Base b = new Derived();
//this really isn't legal, because you can't access a static method via a
//reference(nor should you be able to, imho).
//even if you could, which StaticMethod is being called here? cases could be
//made that it should be Base.StaticMeth od() or Derived.StaticM ethod()
//if Derived.StaticM ethod() is proper, you could end up with unpredictable
//behaviour here.
b.StaticMethod( );
How exactly do you execute the static method without exposing statics (and
some very ugly and troublesome code constructs)? The only way I could think
of currently would be using reflection.
I do not think that there is a technical reason they cannot be added, so
much as a semantic one. Its hard to add such a construct in a way that keeps
the language simple. As such, I don't think it would be a clean thing to add
to the CLR, as it would vastly complicate C# and VB, either by adding a new
keyword(I could see something like staticcall b.StaticMethod( ) or the like,
its ugly though) or by merging static members into the instance member list,
which is also very ugly. I also do not know what kind of a performance issue
it could be.
I really think a contract construct that can specify attributes and
constructors would provide a better solution, especially as the IDE's
mature. "Jonathan Malek" <jm*****@hotmai l.com> wrote in message
news:e4******** *************** ***@posting.goo gle.com... I traced through the responses to the original question, and while I
might have missed something, I feel Chris Capel's question was never
really answered. There were responses about how to do what Chris
wants to do differently, responses that argued the idea, even a nod to
contracts--which I thought missed the whole point.
In the example given, a contract has already been established--in the
form of an abstract class.
I have my own design issue, which brought me to this group in the
first place. I am working on a large number of domain and data mapper
pattern objects. Some of my mappers can handle more than one domain
object, because the domain objects are subclassed.
In order to use a mapper registry (factory) to produce them, I decided
to have each mapper track its mapped types:
public abstract class BaseDataMapper
{
public abstract Type[] MappedTypes{ get ; }
...
}
I think it is reasonable that the author of a mapper should decide
which objects that mapper can map into persistent storage:
public class NamedObjectMapp er : BaseDataMapper
{
public override Type[] MappedTypes
{
get{ return new Type[]{ typeof( ServiceType ), typeof(
UnitType ) } ; )
}
}
Now, during registration of the above mapper type in a factory, I need
some way of registering the supported types--from:
mapperRegistry. GetInstanceFor( ServiceType )
I expect the factory to produce the exact mapper I need. Unless the
property described above is also abstract, I cannot do this without
creating an instance of the mapper during registration. Five mappers?
No big deal. Four hundred mappers in a service layer? No way I want
to create an instance of all of those during registration. Not in an
environment where new domain objects and mappers can be added at
runtime, and their types registered.
And this is the thing: attributes? Come on. The issue here is to
force the mapper author to comply with the contract.
So--why not abstract statics?
Because they are messy, if you read everything posted there were a
number of arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature
that REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just
that purpose(among others, of course). I do however think that a contract
that can handle required attributes should exist, that is a very different
matter entirely.
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:<#h******* *******@tk2msft ngp13.phx.gbl>. .. > What is the rationale behind the decision not to allow abstract
static class > members? It doesn't seem like it's a logically contradictory
concept, or > that the implementation would be difficult or near-impossible. It
seems like > it would be useful. In fact, there's a place in my code that I could
make > good use of it. So why not?
>
> Chris
"Jonathan Malek" <no************ *@hotmail.com> wrote in message
news:eB******** ******@TK2MSFTN GP09.phx.gbl... Daniel,
Correct me if I am wrong, but there is no polymorphic way to access static
methods in C# because C# doesn't support virtual static methods. Other
languages do (Delphi, for one). In other words, the most important argument
for not having abstract statics is that C# doesn't support them. So, I
figure I am missing something. I have read quite a bit on this topic in other lists (the comp.std.c++
list had what seems like a semi-annual celebration on the issue for several
years), trying to understand what the issue is. I suppose I don't quite see
the messy aspect of it all. Everyone raises the same issue--"virtual
static?? Why ever would you want to do such a thing? Oh I see--well, you
know, you could do that this way, or that way..." That's not really an
answer. It can be done, it solves a particular design problem (I've written
one up below that I feel can only be solved this way--or, as you mention,
with contract-enforced attributes), and other languages have shown that. So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that
prohibits such a thing? Better question--is it possible to introduce
CTS-compliant virtual statics? I suppose if the answer to that is no, then
it is pointless wondering why C# doesn't support them.
Well, the primary problem is in cases like this, assume Base has a virtual
static called StaticMethod and Derived is derived from Base.
Base b = new Derived();
//this really isn't legal, because you can't access a static method via a
//reference(nor should you be able to, imho).
//even if you could, which StaticMethod is being called here? cases could be
//made that it should be Base.StaticMeth od() or Derived.StaticM ethod()
//if Derived.StaticM ethod() is proper, you could end up with unpredictable
//behaviour here.
b.StaticMethod( );
How exactly do you execute the static method without exposing statics (and
some very ugly and troublesome code constructs)? The only way I could think
of currently would be using reflection.
I do not think that there is a technical reason they cannot be added, so
much as a semantic one. Its hard to add such a construct in a way that keeps
the language simple. As such, I don't think it would be a clean thing to add
to the CLR, as it would vastly complicate C# and VB, either by adding a new
keyword(I could see something like staticcall b.StaticMethod( ) or the like,
its ugly though) or by merging static members into the instance member list,
which is also very ugly. I also do not know what kind of a performance issue
it could be.
I really think a contract construct that can specify attributes and
constructors would provide a better solution, especially as the IDE's
mature. "Jonathan Malek" <jm*****@hotmai l.com> wrote in message
news:e4******** *************** ***@posting.goo gle.com... I traced through the responses to the original question, and while I
might have missed something, I feel Chris Capel's question was never
really answered. There were responses about how to do what Chris
wants to do differently, responses that argued the idea, even a nod to
contracts--which I thought missed the whole point.
In the example given, a contract has already been established--in the
form of an abstract class.
I have my own design issue, which brought me to this group in the
first place. I am working on a large number of domain and data mapper
pattern objects. Some of my mappers can handle more than one domain
object, because the domain objects are subclassed.
In order to use a mapper registry (factory) to produce them, I decided
to have each mapper track its mapped types:
public abstract class BaseDataMapper
{
public abstract Type[] MappedTypes{ get ; }
...
}
I think it is reasonable that the author of a mapper should decide
which objects that mapper can map into persistent storage:
public class NamedObjectMapp er : BaseDataMapper
{
public override Type[] MappedTypes
{
get{ return new Type[]{ typeof( ServiceType ), typeof(
UnitType ) } ; )
}
}
Now, during registration of the above mapper type in a factory, I need
some way of registering the supported types--from:
mapperRegistry. GetInstanceFor( ServiceType )
I expect the factory to produce the exact mapper I need. Unless the
property described above is also abstract, I cannot do this without
creating an instance of the mapper during registration. Five mappers?
No big deal. Four hundred mappers in a service layer? No way I want
to create an instance of all of those during registration. Not in an
environment where new domain objects and mappers can be added at
runtime, and their types registered.
And this is the thing: attributes? Come on. The issue here is to
force the mapper author to comply with the contract.
So--why not abstract statics?
Because they are messy, if you read everything posted there were a
number of arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature
that REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just
that purpose(among others, of course). I do however think that a contract
that can handle required attributes should exist, that is a very different
matter entirely.
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:<#h******* *******@tk2msft ngp13.phx.gbl>. .. > What is the rationale behind the decision not to allow abstract
static class > members? It doesn't seem like it's a logically contradictory
concept, or > that the implementation would be difficult or near-impossible. It
seems like > it would be useful. In fact, there's a place in my code that I could
make > good use of it. So why not?
>
> Chris
Right--the issue of making class calls from an instance (which I believe Java allows). I agree, not a friendly process, and definitely error prone.
Do you know of a list that's tracking the contact constructs you mention? I would be interested in watching that progress. Thanks for clearing things up for me. "Jonathan Malek" <no************ *@hotmail.com> wrote in message
news:eB******** ******@TK2MSFTN GP09.phx.gbl... Daniel,
Correct me if I am wrong, but there is no polymorphic way to access static
methods in C# because C# doesn't support virtual static methods. Other
languages do (Delphi, for one). In other words, the most important argument
for not having abstract statics is that C# doesn't support them. So, I
figure I am missing something. I have read quite a bit on this topic in other lists (the comp.std.c++
list had what seems like a semi-annual celebration on the issue for several
years), trying to understand what the issue is. I suppose I don't quite see
the messy aspect of it all. Everyone raises the same issue--"virtual
static?? Why ever would you want to do such a thing? Oh I see--well, you
know, you could do that this way, or that way..." That's not really an
answer. It can be done, it solves a particular design problem (I've written
one up below that I feel can only be solved this way--or, as you mention,
with contract-enforced attributes), and other languages have shown that. So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that
prohibits such a thing? Better question--is it possible to introduce
CTS-compliant virtual statics? I suppose if the answer to that is no, then
it is pointless wondering why C# doesn't support them.
Well, the primary problem is in cases like this, assume Base has a virtual
static called StaticMethod and Derived is derived from Base.
Base b = new Derived();
//this really isn't legal, because you can't access a static method via a
//reference(nor should you be able to, imho).
//even if you could, which StaticMethod is being called here? cases could be
//made that it should be Base.StaticMeth od() or Derived.StaticM ethod()
//if Derived.StaticM ethod() is proper, you could end up with unpredictable
//behaviour here.
b.StaticMethod( );
How exactly do you execute the static method without exposing statics (and
some very ugly and troublesome code constructs)? The only way I could think
of currently would be using reflection.
I do not think that there is a technical reason they cannot be added, so
much as a semantic one. Its hard to add such a construct in a way that keeps
the language simple. As such, I don't think it would be a clean thing to add
to the CLR, as it would vastly complicate C# and VB, either by adding a new
keyword(I could see something like staticcall b.StaticMethod( ) or the like,
its ugly though) or by merging static members into the instance member list,
which is also very ugly. I also do not know what kind of a performance issue
it could be.
I really think a contract construct that can specify attributes and
constructors would provide a better solution, especially as the IDE's
mature.
"Jonathan Malek" <jm*****@hotmai l.com> wrote in message
news:e4******** *************** ***@posting.goo gle.com...
> I traced through the responses to the original question, and while I
> might have missed something, I feel Chris Capel's question was never
> really answered. There were responses about how to do what Chris
> wants to do differently, responses that argued the idea, even a nod to
> contracts--which I thought missed the whole point.
>
> In the example given, a contract has already been established--in the
> form of an abstract class.
>
> I have my own design issue, which brought me to this group in the
> first place. I am working on a large number of domain and data mapper
> pattern objects. Some of my mappers can handle more than one domain
> object, because the domain objects are subclassed.
>
> In order to use a mapper registry (factory) to produce them, I decided
> to have each mapper track its mapped types:
>
> public abstract class BaseDataMapper
> {
> public abstract Type[] MappedTypes{ get ; }
> ...
> }
>
> I think it is reasonable that the author of a mapper should decide
> which objects that mapper can map into persistent storage:
>
> public class NamedObjectMapp er : BaseDataMapper
> {
> public override Type[] MappedTypes
> {
> get{ return new Type[]{ typeof( ServiceType ), typeof(
> UnitType ) } ; )
> }
> }
>
> Now, during registration of the above mapper type in a factory, I need
> some way of registering the supported types--from:
>
> mapperRegistry. GetInstanceFor( ServiceType )
>
> I expect the factory to produce the exact mapper I need. Unless the
> property described above is also abstract, I cannot do this without
> creating an instance of the mapper during registration. Five mappers?
> No big deal. Four hundred mappers in a service layer? No way I want
> to create an instance of all of those during registration. Not in an
> environment where new domain objects and mappers can be added at
> runtime, and their types registered.
>
> And this is the thing: attributes? Come on. The issue here is to
> force the mapper author to comply with the contract.
>
> So--why not abstract statics?
>
Because they are messy, if you read everything posted there were a number of arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature that REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just that purpose(among others, of course). I do however think that a contract that can handle required attributes should exist, that is a very different matter entirely.
> "Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:<#h******* *******@tk2msft ngp13.phx.gbl>. ..
> > What is the rationale behind the decision not to allow abstract static class
> > members? It doesn't seem like it's a logically contradictory concept, or > > that the implementation would be difficult or near-impossible. It seems like
> > it would be useful. In fact, there's a place in my code that I could
make
> > good use of it. So why not?
> >
> > Chris
Jonathan Malek <no************ *@hotmail.com> wrote: Right--the issue of making class calls from an instance (which I
believe Java allows). I agree, not a friendly process, and definitely
error prone.
Although Java unfortunately allows it as syntax, it doesn't use the
type of the instance (or even whether or not it's null) at runtime. In
other words, you can do:
Foo x = new Bar();
x.Something();
and it will call Foo.Something() even if there's a Bar.Something()
method.
--
Jon Skeet - <sk***@pobox.co m> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jonathan Malek" <no************ *@hotmail.com> wrote in message
news:u6******** *****@TK2MSFTNG P11.phx.gbl... Right--the issue of making class calls from an instance (which I believe
Java allows). I agree, not a friendly process, and definitely error prone. Do you know of a list that's tracking the contact constructs you mention?
I would be interested in watching that progress. Thanks for clearing things
up for me.
Currently no lists tracking such a contract exists to my knowledge(nor does
any work on such a one exist, AFAIK). I have floated the idea in various
basic forms here a few times with little more results than things like "That
may be useful" or "I could see how that would work" kind of things. I'm
still considering writing up a full fledged proposal & syntax and posting it
here for comments, but time constraints and reaction to the various ideas
I've posted here havn't pushed me to get on it right away. "Jonathan Malek" <no************ *@hotmail.com> wrote in message
news:eB******** ******@TK2MSFTN GP09.phx.gbl... Daniel,
Correct me if I am wrong, but there is no polymorphic way to access
static methods in C# because C# doesn't support virtual static methods. Other
languages do (Delphi, for one). In other words, the most important
argument for not having abstract statics is that C# doesn't support them. So, I
figure I am missing something. I have read quite a bit on this topic in other lists (the comp.std.c++
list had what seems like a semi-annual celebration on the issue for
several years), trying to understand what the issue is. I suppose I don't quite
see the messy aspect of it all. Everyone raises the same issue--"virtual
static?? Why ever would you want to do such a thing? Oh I see--well,
you know, you could do that this way, or that way..." That's not really an
answer. It can be done, it solves a particular design problem (I've
written one up below that I feel can only be solved this way--or, as you
mention, with contract-enforced attributes), and other languages have shown that. So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that
prohibits such a thing? Better question--is it possible to introduce
CTS-compliant virtual statics? I suppose if the answer to that is no,
then it is pointless wondering why C# doesn't support them.
Well, the primary problem is in cases like this, assume Base has a
virtual static called StaticMethod and Derived is derived from Base.
Base b = new Derived();
//this really isn't legal, because you can't access a static method via
a //reference(nor should you be able to, imho).
//even if you could, which StaticMethod is being called here? cases
could be //made that it should be Base.StaticMeth od() or Derived.StaticM ethod()
//if Derived.StaticM ethod() is proper, you could end up with
unpredictable //behaviour here.
b.StaticMethod( );
How exactly do you execute the static method without exposing statics
(and some very ugly and troublesome code constructs)? The only way I could
think of currently would be using reflection.
I do not think that there is a technical reason they cannot be added, so
much as a semantic one. Its hard to add such a construct in a way that
keeps the language simple. As such, I don't think it would be a clean thing to
add to the CLR, as it would vastly complicate C# and VB, either by adding a
new keyword(I could see something like staticcall b.StaticMethod( ) or the
like, its ugly though) or by merging static members into the instance member
list, which is also very ugly. I also do not know what kind of a performance
issue it could be.
I really think a contract construct that can specify attributes and
constructors would provide a better solution, especially as the IDE's
mature.
> "Jonathan Malek" <jm*****@hotmai l.com> wrote in message
> news:e4******** *************** ***@posting.goo gle.com...
> > I traced through the responses to the original question, and while
I > > might have missed something, I feel Chris Capel's question was
never > > really answered. There were responses about how to do what Chris
> > wants to do differently, responses that argued the idea, even a
nod to > > contracts--which I thought missed the whole point.
> >
> > In the example given, a contract has already been established--in
the > > form of an abstract class.
> >
> > I have my own design issue, which brought me to this group in the
> > first place. I am working on a large number of domain and data
mapper > > pattern objects. Some of my mappers can handle more than one
domain > > object, because the domain objects are subclassed.
> >
> > In order to use a mapper registry (factory) to produce them, I
decided > > to have each mapper track its mapped types:
> >
> > public abstract class BaseDataMapper
> > {
> > public abstract Type[] MappedTypes{ get ; }
> > ...
> > }
> >
> > I think it is reasonable that the author of a mapper should decide
> > which objects that mapper can map into persistent storage:
> >
> > public class NamedObjectMapp er : BaseDataMapper
> > {
> > public override Type[] MappedTypes
> > {
> > get{ return new Type[]{ typeof( ServiceType ), typeof(
> > UnitType ) } ; )
> > }
> > }
> >
> > Now, during registration of the above mapper type in a factory, I
need > > some way of registering the supported types--from:
> >
> > mapperRegistry. GetInstanceFor( ServiceType )
> >
> > I expect the factory to produce the exact mapper I need. Unless
the > > property described above is also abstract, I cannot do this
without > > creating an instance of the mapper during registration. Five
mappers? > > No big deal. Four hundred mappers in a service layer? No way I
want > > to create an instance of all of those during registration. Not in
an > > environment where new domain objects and mappers can be added at
> > runtime, and their types registered.
> >
> > And this is the thing: attributes? Come on. The issue here is to
> > force the mapper author to comply with the contract.
> >
> > So--why not abstract statics?
> >
> Because they are messy, if you read everything posted there were a
number of > arguments. The most important one is that there is no polymorphic
way to > access static methods, you are forced to use reflection and any
feature that > REQUIRES reflection to use it is not something that should exist,
IMHO. > I would not ever use statics in that manner, attributes exist for
just that > purpose(among others, of course). I do however think that a contract
that > can handle required attributes should exist, that is a very
different matter > entirely.
>
> > "Chris Capel" <ch***@ibanktec h.comnet> wrote in message
> news:<#h******* *******@tk2msft ngp13.phx.gbl>. ..
> > > What is the rationale behind the decision not to allow abstract
static > class
> > > members? It doesn't seem like it's a logically contradictory
concept, or > > > that the implementation would be difficult or near-impossible.
It seems > like
> > > it would be useful. In fact, there's a place in my code that I
could > make
> > > good use of it. So why not?
> > >
> > > Chris
I started reading this thread, because I was talking about something along
these lines at work today with a fellow developer. I have some functions
that are specific to one component of the application that we are
developing. These functions will be used by several classes however. His
suggestion was to make static functions in a new class.
I have come to realize that this thread is not exactly the same as what I
was thinking about. This thread, as far as I can tell, is discussing having
"abstract static members" in a class as opposed to having "public static
members" in an abstract class, which you can do. My reasoning behind having
the abstract class with public static functions was to prevent anyone from
creating an unnecessary object from the class. This may not be the best way
of doing what I was after, but it works.
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. .. What is the rationale behind the decision not to allow abstract static
class members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems
like it would be useful. In fact, there's a place in my code that I could make
good use of it. So why not?
Chris
"Kerry Sanders" <di****@yahoo.c om> wrote in message
news:Bh******** **********@bign ews4.bellsouth. net... I started reading this thread, because I was talking about something along
these lines at work today with a fellow developer. I have some functions
that are specific to one component of the application that we are
developing. These functions will be used by several classes however. His
suggestion was to make static functions in a new class.
I have come to realize that this thread is not exactly the same as what I
was thinking about. This thread, as far as I can tell, is discussing
having "abstract static members" in a class as opposed to having "public static
members" in an abstract class, which you can do. My reasoning behind
having the abstract class with public static functions was to prevent anyone from
creating an unnecessary object from the class. This may not be the best
way of doing what I was after, but it works.
It works, but that allows the class to be derived from. Perhaps a sealed
class suits you better?
"Chris Capel" <ch***@ibanktec h.comnet> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. .. What is the rationale behind the decision not to allow abstract static
class members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems
like it would be useful. In fact, there's a place in my code that I could
make good use of it. So why not?
Chris
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Murat Tasan |
last post by:
so here is another general question about java...
why can't you declare an abstract static method.
i can envision the case (indeed i have experienced the case) where one
would want an abstracct superclass, with an abstract method such that all
subclasses that implement this method make that method static.
basically, the abstract class declares an abstract method that should be
static for all implementations (for example a factory...
|
by: Daedalus.OS |
last post by:
Ok first I'm pretty new to OOP, so my question may sound stupid to some of
you. If the only answer you can provide is "get a book about OOP" then don't
loose your time and mine cause it's already ordered. I'm just too curious
about this one to wait for the book.
I would like to know is if it's good php programming practice to use
abstract classes instead of singleton classes. For exemple a login class.
I've made one as an abstract class...
|
by: Sunny |
last post by:
Hi again,
in the past I have posted here a problem with static methods and
abstract classes, and Jon Skeet and Richard Lowe have helped me to
clarify the things.
But now I have found another problem (I have posted similar thing in
vs.ide newsgroup, but I do not know if this is and IDE or C# problem, so
I post it here also).
|
by: Mike Ruane-Torr |
last post by:
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...
|
by: pali |
last post by:
Hi,
I was just wondering, why is not possible to make a member of a class BOTH
abstract and static? MSDN says just that's in an error, not why this is so.
In a nutshell, I need this:
I have an abstract base class called EntityBase that all my other business
objects are derived from. I want to be able to load and save them in a
generic manner. I use a static method called EntityBase.GetByID(int id) and a
member method called...
| | |
by: Brybot |
last post by:
Apparently it is not possible for a static class to extend an abstract
class? I was wondering how else I might be able to go about my problem
here?
I have a base class Parent which has a static method and an abstract
method.
public abstract class Parent {
public static bool True()
|
by: Vedo |
last post by:
ref struct XXX abstract sealed
{
literal int A = 5;
};
The definition above gives me the compiler warning "C4693: a sealed abstract
class cannot have any instance members 'A'". The equivalent definition is
perfectly legal in other CLR languages. For example in C#;
static class XXX
|
by: jacob navia |
last post by:
Abstract:
Continuing the discussion about abstract data types, in this
discussion group, a string collection data type is presented,
patterned after the collection in C# and similar languages (Java).
It stores character strings, and resizes itself to accommodate
new strings when needed.
Interface:
----------
|
by: pinki panda |
last post by:
i want to knw the diff between static class and abstract class .i would appreciate if its followed by example
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
