abstract static?

[Jasper Kent]

Re: abstract static?

Without wanting to harp on about C++ templates, they do do the job, but
clearly they do have the drawback that there is not an explicit listing of
what is required from a class, it's implicit from the various things that
you ask the class to do.

This does mean, however, that the specification of requirements is bound
inextricably with its usage. This gives us a couple of advantages:

1) The specification can't go 'over-the-top' asking for requirements that
are never used and therefore wasting implementer's time and causing code
bloat. The C++ template mechanism is very good at not forming instantiations
that can never be called.

2) There is no risk that (as there would be with specification plus
reflection) that at runtime a requirement will be discovered that was
missing from the specification.

Templates give a full list of non-compliance at compile-time. The problem is
that this list is unclear and scattered about the full error list. It might
be useful to develop a tool which strips out all those non-compliances from
the error list and presents a summary of why a class fails to comply. (Some
C++ compilers may already do this.)

Regards,

Jasper Kent.

"Daniel O'Connell" <onyxkirx@comca st.net> wrote in message
news:N_66b.3679 30$Ho3.53743@sc crnsc03...[color=blue]
> Since I'm still researching alot of what I was babbling about, do you know
> of any languages that support the level of a contract that requires
> specification of constructors and the like? I've yet to find one that
> explicit.
> I'm still playing with some random syntaxes to simplify(or remove the need
> for) reflection in many cases and allow a specification of a number of
> things an object needs to be aware of...not that it'll ever get[/color]
implemented,[color=blue]
> but I find it an interesting research project
> "Jasper Kent" <jasper_kent@ho tmail.com> wrote in message
> news:eZkJNP9cDH A.3992@TK2MSFTN GP11.phx.gbl...[color=green]
> > It's not just that static methods can't be abstract, they can't be[/color][/color]
virtual[color=blue][color=green]
> > (which all abstract methods, by definition, are).
> >
> > The reason is simple.
> >
> > A virtual method is one whose implementation is selected on the basis of[/color]
> the[color=green]
> > type of the object on which it is called. Static methods are not called[/color][/color]
on[color=blue][color=green]
> > an object, therefore that sort of determination cannot be made.
> >
> > What you may be after is what might be called a 'contract' rather than[/color][/color]
an[color=blue][color=green]
> > interface. This isn't available in C#. There's quite a lot of discussion[/color]
> on[color=green]
> > that in another thread, under the title of 'Re: C# language feature
> > proposal' on this newsgroup, dated 1/9/03.
> >
> > Regards,
> >
> > Jasper Kent.
> >
> >
> >
> >
> > "Chris Capel" <chris@ibanktec h.comnet> wrote in message
> > news:%23h4xIX8c DHA.3708@tk2msf tngp13.phx.gbl. ..[color=darkred]
> > > What is the rationale behind the decision not to allow abstract static[/color]
> > class[color=darkred]
> > > members? It doesn't seem like it's a logically contradictory concept,[/color][/color][/color]
or[color=blue][color=green][color=darkred]
> > > that the implementation would be difficult or near-impossible. It[/color][/color][/color]
seems[color=blue][color=green]
> > like[color=darkred]
> > > it would be useful. In fact, there's a place in my code that I could[/color][/color]
> make[color=green][color=darkred]
> > > good use of it. So why not?
> > >
> > > Chris
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Daniel O'Connell]

Re: abstract static?


"Jasper Kent" <jasper_kent@ho tmail.com> wrote in message
news:uSSZsdGdDH A.3448@TK2MSFTN GP11.phx.gbl...[color=blue]
> Without wanting to harp on about C++ templates, they do do the job, but
> clearly they do have the drawback that there is not an explicit listing of
> what is required from a class, it's implicit from the various things that
> you ask the class to do.
>[/color]
Problem is, I personally don't really care for templates and find them to
generally cause me more trouble than they solve(I HATE getting errors in
source files i didn't even know existed and I seem to have a knack for
breaking templated code). I never liked C++ in the first place (used C than
C#, skipped the C++ nightmare for the most part), and templates always made
the language less pleasent...I do not think it would be a good thing to
introduce that kinda trouble into C# or the framework as a whole. Plus,
templates don't provide any sort of easy self-documentation nor are they
easy to write and read in a single sitting, in the concept I have sitting in
my head, you could just sit down and scan about 40 lines of source max and
understand what is required of you and what restrictions sit on you (ie,
what permissions will exist for the module).
Anyway, I don't want to start a C++ template discussion, thats just my
biased opinion on a technology I do not fully understand. ;)
[color=blue]
> This does mean, however, that the specification of requirements is bound
> inextricably with its usage. This gives us a couple of advantages:
>
> 1) The specification can't go 'over-the-top' asking for requirements that
> are never used and therefore wasting implementer's time and causing code
> bloat. The C++ template mechanism is very good at not forming[/color]
instantiations[color=blue]
> that can never be called.[/color]

In the design I want, there would be a few new ways to add functionality
thats not needed, most notably the instance of forcing attributes or
something where the loader doesn't check for them (although the contractual
construct probably would on load aswell...not sure), but nothing that is to
big of a deal. As it stands the biggest problem is when interfaces specify a
method that the external loader never bothers to use.
[color=blue]
>
> 2) There is no risk that (as there would be with specification plus
> reflection) that at runtime a requirement will be discovered that was
> missing from the specification.
>[/color]

I'm not quite sure what you mean here, part of the goal of this crazy
experiment is to provide a construct that does the reflection nessecery to
verify and return the object specified, to both provide a specification and
to remove the need to write similar reflection code for every plugin or
module loader you write. It wouldn't be too difficult to design a class gen
that produced a factory or something that follows a set of rules and
performs the reflection and a implementing class, that would be my first
goal if I ever get teh design up and moving, but runtime & compiler level
enforcement would be the penultimate.
[color=blue]
> Templates give a full list of non-compliance at compile-time. The problem[/color]
is[color=blue]
> that this list is unclear and scattered about the full error list. It[/color]
might[color=blue]
> be useful to develop a tool which strips out all those non-compliances[/color]
from[color=blue]
> the error list and presents a summary of why a class fails to comply.[/color]
(Some[color=blue]
> C++ compilers may already do this.)
>
> Regards,
>
> Jasper Kent.
>
> "Daniel O'Connell" <onyxkirx@comca st.net> wrote in message
> news:N_66b.3679 30$Ho3.53743@sc crnsc03...[color=green]
> > Since I'm still researching alot of what I was babbling about, do you[/color][/color]
know[color=blue][color=green]
> > of any languages that support the level of a contract that requires
> > specification of constructors and the like? I've yet to find one that
> > explicit.
> > I'm still playing with some random syntaxes to simplify(or remove the[/color][/color]
need[color=blue][color=green]
> > for) reflection in many cases and allow a specification of a number of
> > things an object needs to be aware of...not that it'll ever get[/color]
> implemented,[color=green]
> > but I find it an interesting research project
> > "Jasper Kent" <jasper_kent@ho tmail.com> wrote in message
> > news:eZkJNP9cDH A.3992@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > It's not just that static methods can't be abstract, they can't be[/color][/color]
> virtual[color=green][color=darkred]
> > > (which all abstract methods, by definition, are).
> > >
> > > The reason is simple.
> > >
> > > A virtual method is one whose implementation is selected on the basis[/color][/color][/color]
of[color=blue][color=green]
> > the[color=darkred]
> > > type of the object on which it is called. Static methods are not[/color][/color][/color]
called[color=blue]
> on[color=green][color=darkred]
> > > an object, therefore that sort of determination cannot be made.
> > >
> > > What you may be after is what might be called a 'contract' rather than[/color][/color]
> an[color=green][color=darkred]
> > > interface. This isn't available in C#. There's quite a lot of[/color][/color][/color]
discussion[color=blue][color=green]
> > on[color=darkred]
> > > that in another thread, under the title of 'Re: C# language feature
> > > proposal' on this newsgroup, dated 1/9/03.
> > >
> > > Regards,
> > >
> > > Jasper Kent.
> > >
> > >
> > >
> > >
> > > "Chris Capel" <chris@ibanktec h.comnet> wrote in message
> > > news:%23h4xIX8c DHA.3708@tk2msf tngp13.phx.gbl. ..
> > > > What is the rationale behind the decision not to allow abstract[/color][/color][/color]
static[color=blue][color=green][color=darkred]
> > > class
> > > > members? It doesn't seem like it's a logically contradictory[/color][/color][/color]
concept,[color=blue]
> or[color=green][color=darkred]
> > > > that the implementation would be difficult or near-impossible. It[/color][/color]
> seems[color=green][color=darkred]
> > > like
> > > > it would be useful. In fact, there's a place in my code that I could[/color]
> > make[color=darkred]
> > > > good use of it. So why not?
> > > >
> > > > Chris
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Jonathan Malek]

Re: abstract static?

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?

"Chris Capel" <chris@ibanktec h.comnet> wrote in message news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=blue]
> 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[/color]

[Jonathan Malek]

Re: abstract static?

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?

"Chris Capel" <chris@ibanktec h.comnet> wrote in message news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=blue]
> 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[/color]

[Daniel O'Connell]

Re: abstract static?


"Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...[color=blue]
> 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?
>[/color]
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.
[color=blue]
> "Chris Capel" <chris@ibanktec h.comnet> wrote in message[/color]
news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=blue][color=green]
> > What is the rationale behind the decision not to allow abstract static[/color][/color]
class[color=blue][color=green]
> > members? It doesn't seem like it's a logically contradictory concept, or
> > that the implementation would be difficult or near-impossible. It seems[/color][/color]
like[color=blue][color=green]
> > it would be useful. In fact, there's a place in my code that I could[/color][/color]
make[color=blue][color=green]
> > good use of it. So why not?
> >
> > Chris[/color][/color]

[Daniel O'Connell]

Re: abstract static?


"Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...[color=blue]
> 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?
>[/color]
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.
[color=blue]
> "Chris Capel" <chris@ibanktec h.comnet> wrote in message[/color]
news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=blue][color=green]
> > What is the rationale behind the decision not to allow abstract static[/color][/color]
class[color=blue][color=green]
> > members? It doesn't seem like it's a logically contradictory concept, or
> > that the implementation would be difficult or near-impossible. It seems[/color][/color]
like[color=blue][color=green]
> > it would be useful. In fact, there's a place in my code that I could[/color][/color]
make[color=blue][color=green]
> > good use of it. So why not?
> >
> > Chris[/color][/color]

[Jonathan Malek]

Re: abstract static?

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.[color=blue]
> "Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
> news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...[color=green]
> > 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?
> >[/color]
> 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.
>[color=green]
> > "Chris Capel" <chris@ibanktec h.comnet> wrote in message[/color]
> news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=green][color=darkred]
> > > What is the rationale behind the decision not to allow abstract static[/color][/color]
> class[color=green][color=darkred]
> > > members? It doesn't seem like it's a logically contradictory concept, or
> > > that the implementation would be difficult or near-impossible. It seems[/color][/color]
> like[color=green][color=darkred]
> > > it would be useful. In fact, there's a place in my code that I could[/color][/color]
> make[color=green][color=darkred]
> > > good use of it. So why not?
> > >
> > > Chris[/color][/color][/color]

[Jonathan Malek]

Re: abstract static?

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.[color=blue]
> "Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
> news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...[color=green]
> > 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?
> >[/color]
> 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.
>[color=green]
> > "Chris Capel" <chris@ibanktec h.comnet> wrote in message[/color]
> news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=green][color=darkred]
> > > What is the rationale behind the decision not to allow abstract static[/color][/color]
> class[color=green][color=darkred]
> > > members? It doesn't seem like it's a logically contradictory concept, or
> > > that the implementation would be difficult or near-impossible. It seems[/color][/color]
> like[color=green][color=darkred]
> > > it would be useful. In fact, there's a place in my code that I could[/color][/color]
> make[color=green][color=darkred]
> > > good use of it. So why not?
> > >
> > > Chris[/color][/color][/color]

[Daniel O'Connell]

Re: abstract static?


"Jonathan Malek" <no_jmmalek_spa m@hotmail.com> wrote in message
news:eBjYox9iDH A.1672@TK2MSFTN GP09.phx.gbl...[color=blue]
> Daniel,
> Correct me if I am wrong, but there is no polymorphic way to access static[/color]
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.[color=blue]
> I have read quite a bit on this topic in other lists (the comp.std.c++[/color]
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.[color=blue]
> So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that[/color]
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.
[color=blue][color=green]
> > "Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
> > news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...[color=darkred]
> > > 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?
> > >[/color]
> > Because they are messy, if you read everything posted there were a[/color][/color]
number of[color=blue][color=green]
> > 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[/color][/color]
that[color=blue][color=green]
> > 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[/color][/color]
that[color=blue][color=green]
> > purpose(among others, of course). I do however think that a contract[/color][/color]
that[color=blue][color=green]
> > can handle required attributes should exist, that is a very different[/color][/color]
matter[color=blue][color=green]
> > entirely.
> >[color=darkred]
> > > "Chris Capel" <chris@ibanktec h.comnet> wrote in message[/color]
> > news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=darkred]
> > > > What is the rationale behind the decision not to allow abstract[/color][/color][/color]
static[color=blue][color=green]
> > class[color=darkred]
> > > > members? It doesn't seem like it's a logically contradictory[/color][/color][/color]
concept, or[color=blue][color=green][color=darkred]
> > > > that the implementation would be difficult or near-impossible. It[/color][/color][/color]
seems[color=blue][color=green]
> > like[color=darkred]
> > > > it would be useful. In fact, there's a place in my code that I could[/color]
> > make[color=darkred]
> > > > good use of it. So why not?
> > > >
> > > > Chris[/color][/color][/color]

[Daniel O'Connell]

Re: abstract static?


"Jonathan Malek" <no_jmmalek_spa m@hotmail.com> wrote in message
news:eBjYox9iDH A.1672@TK2MSFTN GP09.phx.gbl...[color=blue]
> Daniel,
> Correct me if I am wrong, but there is no polymorphic way to access static[/color]
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.[color=blue]
> I have read quite a bit on this topic in other lists (the comp.std.c++[/color]
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.[color=blue]
> So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that[/color]
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.
[color=blue][color=green]
> > "Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
> > news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...[color=darkred]
> > > 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?
> > >[/color]
> > Because they are messy, if you read everything posted there were a[/color][/color]
number of[color=blue][color=green]
> > 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[/color][/color]
that[color=blue][color=green]
> > 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[/color][/color]
that[color=blue][color=green]
> > purpose(among others, of course). I do however think that a contract[/color][/color]
that[color=blue][color=green]
> > can handle required attributes should exist, that is a very different[/color][/color]
matter[color=blue][color=green]
> > entirely.
> >[color=darkred]
> > > "Chris Capel" <chris@ibanktec h.comnet> wrote in message[/color]
> > news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..[color=darkred]
> > > > What is the rationale behind the decision not to allow abstract[/color][/color][/color]
static[color=blue][color=green]
> > class[color=darkred]
> > > > members? It doesn't seem like it's a logically contradictory[/color][/color][/color]
concept, or[color=blue][color=green][color=darkred]
> > > > that the implementation would be difficult or near-impossible. It[/color][/color][/color]
seems[color=blue][color=green]
> > like[color=darkred]
> > > > it would be useful. In fact, there's a place in my code that I could[/color]
> > make[color=darkred]
> > > > good use of it. So why not?
> > > >
> > > > Chris[/color][/color][/color]

[Jonathan Malek]

Re: Re: abstract static?

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.[color=blue]
> "Jonathan Malek" <no_jmmalek_spa m@hotmail.com> wrote in message
> news:eBjYox9iDH A.1672@TK2MSFTN GP09.phx.gbl...[color=green]
> > Daniel,
> > Correct me if I am wrong, but there is no polymorphic way to access static[/color]
> 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.[color=green]
> > I have read quite a bit on this topic in other lists (the comp.std.c++[/color]
> 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.[color=green]
> > So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that[/color]
> 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.
>[color=green][color=darkred]
> > > "Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
> > > news:e4957bf2.0 310051532.26b1f ab5@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[/color][/color]
> number of[color=green][color=darkred]
> > > 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[/color][/color]
> that[color=green][color=darkred]
> > > 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[/color][/color]
> that[color=green][color=darkred]
> > > purpose(among others, of course). I do however think that a contract[/color][/color]
> that[color=green][color=darkred]
> > > can handle required attributes should exist, that is a very different[/color][/color]
> matter[color=green][color=darkred]
> > > entirely.
> > >
> > > > "Chris Capel" <chris@ibanktec h.comnet> wrote in message
> > > news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..
> > > > > What is the rationale behind the decision not to allow abstract[/color][/color]
> static[color=green][color=darkred]
> > > class
> > > > > members? It doesn't seem like it's a logically contradictory[/color][/color]
> concept, or[color=green][color=darkred]
> > > > > that the implementation would be difficult or near-impossible. It[/color][/color]
> seems[color=green][color=darkred]
> > > 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[/color][/color][/color]

[Jon Skeet [C# MVP]]

Re: Re: abstract static?

Jonathan Malek <no_jmmalek_spa m@hotmail.com> wrote:[color=blue]
> 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.[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

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

[Daniel O'Connell]

Re: Re: abstract static?


"Jonathan Malek" <no_jmmalek_spa m@hotmail.com> wrote in message
news:u6ixYeBjDH A.548@TK2MSFTNG P11.phx.gbl...[color=blue]
> Right--the issue of making class calls from an instance (which I believe[/color]
Java allows). I agree, not a friendly process, and definitely error prone.[color=blue]
> Do you know of a list that's tracking the contact constructs you mention?[/color]
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.[color=blue][color=green]
> > "Jonathan Malek" <no_jmmalek_spa m@hotmail.com> wrote in message
> > news:eBjYox9iDH A.1672@TK2MSFTN GP09.phx.gbl...[color=darkred]
> > > Daniel,
> > > Correct me if I am wrong, but there is no polymorphic way to access[/color][/color][/color]
static[color=blue][color=green]
> > methods in C# because C# doesn't support virtual static methods. Other
> > languages do (Delphi, for one). In other words, the most important[/color][/color]
argument[color=blue][color=green]
> > for not having abstract statics is that C# doesn't support them. So, I
> > figure I am missing something.[color=darkred]
> > > I have read quite a bit on this topic in other lists (the comp.std.c++[/color]
> > list had what seems like a semi-annual celebration on the issue for[/color][/color]
several[color=blue][color=green]
> > years), trying to understand what the issue is. I suppose I don't quite[/color][/color]
see[color=blue][color=green]
> > 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,[/color][/color]
you[color=blue][color=green]
> > 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[/color][/color]
written[color=blue][color=green]
> > one up below that I feel can only be solved this way--or, as you[/color][/color]
mention,[color=blue][color=green]
> > with contract-enforced attributes), and other languages have shown that.[color=darkred]
> > > So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that[/color]
> > prohibits such a thing? Better question--is it possible to introduce
> > CTS-compliant virtual statics? I suppose if the answer to that is no,[/color][/color]
then[color=blue][color=green]
> > it is pointless wondering why C# doesn't support them.
> >
> > Well, the primary problem is in cases like this, assume Base has a[/color][/color]
virtual[color=blue][color=green]
> > 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[/color][/color]
a[color=blue][color=green]
> > //reference(nor should you be able to, imho).
> > //even if you could, which StaticMethod is being called here? cases[/color][/color]
could be[color=blue][color=green]
> > //made that it should be Base.StaticMeth od() or Derived.StaticM ethod()
> > //if Derived.StaticM ethod() is proper, you could end up with[/color][/color]
unpredictable[color=blue][color=green]
> > //behaviour here.
> > b.StaticMethod( );
> >
> > How exactly do you execute the static method without exposing statics[/color][/color]
(and[color=blue][color=green]
> > some very ugly and troublesome code constructs)? The only way I could[/color][/color]
think[color=blue][color=green]
> > 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[/color][/color]
keeps[color=blue][color=green]
> > the language simple. As such, I don't think it would be a clean thing to[/color][/color]
add[color=blue][color=green]
> > to the CLR, as it would vastly complicate C# and VB, either by adding a[/color][/color]
new[color=blue][color=green]
> > keyword(I could see something like staticcall b.StaticMethod( ) or the[/color][/color]
like,[color=blue][color=green]
> > its ugly though) or by merging static members into the instance member[/color][/color]
list,[color=blue][color=green]
> > which is also very ugly. I also do not know what kind of a performance[/color][/color]
issue[color=blue][color=green]
> > 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.
> >[color=darkred]
> > > > "Jonathan Malek" <jmmalek@hotmai l.com> wrote in message
> > > > news:e4957bf2.0 310051532.26b1f ab5@posting.goo gle.com...
> > > > > I traced through the responses to the original question, and while[/color][/color][/color]
I[color=blue][color=green][color=darkred]
> > > > > might have missed something, I feel Chris Capel's question was[/color][/color][/color]
never[color=blue][color=green][color=darkred]
> > > > > really answered. There were responses about how to do what Chris
> > > > > wants to do differently, responses that argued the idea, even a[/color][/color][/color]
nod to[color=blue][color=green][color=darkred]
> > > > > contracts--which I thought missed the whole point.
> > > > >
> > > > > In the example given, a contract has already been established--in[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > 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[/color][/color][/color]
mapper[color=blue][color=green][color=darkred]
> > > > > pattern objects. Some of my mappers can handle more than one[/color][/color][/color]
domain[color=blue][color=green][color=darkred]
> > > > > object, because the domain objects are subclassed.
> > > > >
> > > > > In order to use a mapper registry (factory) to produce them, I[/color][/color][/color]
decided[color=blue][color=green][color=darkred]
> > > > > 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[/color][/color][/color]
need[color=blue][color=green][color=darkred]
> > > > > some way of registering the supported types--from:
> > > > >
> > > > > mapperRegistry. GetInstanceFor( ServiceType )
> > > > >
> > > > > I expect the factory to produce the exact mapper I need. Unless[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > property described above is also abstract, I cannot do this[/color][/color][/color]
without[color=blue][color=green][color=darkred]
> > > > > creating an instance of the mapper during registration. Five[/color][/color][/color]
mappers?[color=blue][color=green][color=darkred]
> > > > > No big deal. Four hundred mappers in a service layer? No way I[/color][/color][/color]
want[color=blue][color=green][color=darkred]
> > > > > to create an instance of all of those during registration. Not in[/color][/color][/color]
an[color=blue][color=green][color=darkred]
> > > > > 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[/color]
> > number of[color=darkred]
> > > > arguments. The most important one is that there is no polymorphic[/color][/color][/color]
way to[color=blue][color=green][color=darkred]
> > > > access static methods, you are forced to use reflection and any[/color][/color][/color]
feature[color=blue][color=green]
> > that[color=darkred]
> > > > REQUIRES reflection to use it is not something that should exist,[/color][/color][/color]
IMHO.[color=blue][color=green][color=darkred]
> > > > I would not ever use statics in that manner, attributes exist for[/color][/color][/color]
just[color=blue][color=green]
> > that[color=darkred]
> > > > purpose(among others, of course). I do however think that a contract[/color]
> > that[color=darkred]
> > > > can handle required attributes should exist, that is a very[/color][/color][/color]
different[color=blue][color=green]
> > matter[color=darkred]
> > > > entirely.
> > > >
> > > > > "Chris Capel" <chris@ibanktec h.comnet> wrote in message
> > > > news:<#h4xIX8cD HA.3708@tk2msft ngp13.phx.gbl>. ..
> > > > > > What is the rationale behind the decision not to allow abstract[/color]
> > static[color=darkred]
> > > > class
> > > > > > members? It doesn't seem like it's a logically contradictory[/color]
> > concept, or[color=darkred]
> > > > > > that the implementation would be difficult or near-impossible.[/color][/color][/color]
It[color=blue][color=green]
> > seems[color=darkred]
> > > > like
> > > > > > it would be useful. In fact, there's a place in my code that I[/color][/color][/color]
could[color=blue][color=green][color=darkred]
> > > > make
> > > > > > good use of it. So why not?
> > > > > >
> > > > > > Chris[/color][/color][/color]

[Kerry Sanders]

Re: abstract static?

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" <chris@ibanktec h.comnet> wrote in message
news:%23h4xIX8c DHA.3708@tk2msf tngp13.phx.gbl. ..[color=blue]
> What is the rationale behind the decision not to allow abstract static[/color]
class[color=blue]
> members? It doesn't seem like it's a logically contradictory concept, or
> that the implementation would be difficult or near-impossible. It seems[/color]
like[color=blue]
> 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
>
>[/color]

[Daniel O'Connell]

Re: abstract static?


"Kerry Sanders" <dirgon@yahoo.c om> wrote in message
news:Bh2kb.1237 8$h47.7212@bign ews4.bellsouth. net...[color=blue]
> 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[/color]
having[color=blue]
> "abstract static members" in a class as opposed to having "public static
> members" in an abstract class, which you can do. My reasoning behind[/color]
having[color=blue]
> 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[/color]
way[color=blue]
> of doing what I was after, but it works.[/color]

It works, but that allows the class to be derived from. Perhaps a sealed
class suits you better?
[color=blue]
>
>
>
>
> "Chris Capel" <chris@ibanktec h.comnet> wrote in message
> news:%23h4xIX8c DHA.3708@tk2msf tngp13.phx.gbl. ..[color=green]
> > What is the rationale behind the decision not to allow abstract static[/color]
> class[color=green]
> > members? It doesn't seem like it's a logically contradictory concept, or
> > that the implementation would be difficult or near-impossible. It seems[/color]
> like[color=green]
> > it would be useful. In fact, there's a place in my code that I could[/color][/color]
make[color=blue][color=green]
> > good use of it. So why not?
> >
> > Chris
> >
> >[/color]
>
>[/color]