|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Lack of OO support for stateless programmingprogramming is at a premium. This often means all of the public methods on a class are defined as static. I often find that the .Net framework has poor support for doing this. Interface definitions don't allow static methods, so I can't build a stateless contracts, and abstract classes cannot define a stateless method as abstract. There's also no support for the concept of a virtual or overridable stateless method. (Please, nobody tell me about vtables and class instances - I know how it works). In terms of an Interface, I would like code to end up looking like this: public interface IExample { static int SomeFunction(int x, int y); } public class ConcreteClass : IExample { public static int SomeFunction(int x, int y) { return x + y; } } In terms on a base class supporting shared methods, a similar approach would be nice: public abstract class ExampleBase { public static abstract int Sample(int x, int y); } public class ExampleConcrete : ExampleBase { public static override int Sample(int x, int y) { return x + y; } } It seems as if each of these features would enable a richer development environment for building stateless components. The lack of this features seems to often affect class design, even within the MS framework. For example, the data layers generated by the .Net 2.0 Data Adapter class don't use stateless data methods, and yet most hand-rolled data layers do. Anyone have any suggestions of a solid way to do contract based development and still enforce statless programming? "Chris Mullins" <cmull***@yahoo.com> wrote in message Singletons and Factory methods.news:ORqnoNZvGHA.3264@TK2MSFTNGP03.phx.gbl... >I tend to build high performance system, and when doing this stateless >programming is at a premium. This often means all of the public methods on >a class are defined as static. > .... > Anyone have any suggestions of a solid way to do contract based > development and still enforce statless programming? > David "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote While these are two common patterns, neither one really solves the > > "Chris Mullins" <cmull***@yahoo.com> wrote >>I tend to build high performance system, and when doing this stateless >>programming is at a premium. This often means all of the public methods on >>a class are defined as static. >> Anyone have any suggestions of a solid way to do contract based >> development and still enforce statless programming? > Singletons and Factory methods. underlying problem. There's no way in code to say, "Any class that implementes this interface must be a singleton". Even if you could, everything ends up looking like, "MyClass.Instance.GetData", which is hardly idea. While I love the pattern and have used it quite a bit, it's not quite what I'm looking for. Static Factory Methods miss out on the Contract portion - there's no way to enfore the contracts. If an Interface provided for static methods, but without that.... -- Chris Mullins Seems that you want programming by contract and multiple inheritance - how
about Eiffel? Regards Chris Saunders Show quote "Chris Mullins" <cmull***@yahoo.com> wrote in message news:uiEijVavGHA.3936@TK2MSFTNGP04.phx.gbl... > "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote >> >> "Chris Mullins" <cmull***@yahoo.com> wrote > >>>I tend to build high performance system, and when doing this stateless >>>programming is at a premium. This often means all of the public methods >>>on a class are defined as static. > >>> Anyone have any suggestions of a solid way to do contract based >>> development and still enforce statless programming? > >> Singletons and Factory methods. > > While these are two common patterns, neither one really solves the > underlying problem. > > There's no way in code to say, "Any class that implementes this interface > must be a singleton". Even if you could, everything ends up looking like, > "MyClass.Instance.GetData", which is hardly idea. While I love the pattern > and have used it quite a bit, it's not quite what I'm looking for. > > Static Factory Methods miss out on the Contract portion - there's no way > to enfore the contracts. If an Interface provided for static methods, but > without that.... > > -- > Chris Mullins > It's not really Multiple Inheritence that I'm looking for (although that
would be nice, and I miss it from my C++ days), but the ability to have static methods in the inheritence tree. I want, specifically, a way to say, "This method is stateless", and have that enforced by a base class or an Interface. Right now the only way to enfore that it to put the static keyword on a method - but there's no good way to broadly enfore this at the architecture level. It would be nice, while I'm wishing, to have overridable static members on a base class as well. I looked into Eiffel a while ago - I lived in Santa Barbara, and the language was invented there so I ended up at several presentations put on about it. At the time, Eiffel was running atop the .Net CLR, which means it can't really have the funcationality I'm looking for, as (to the best of my knowledge) the CLR doesn't support what I'm describing. I'm happy with C#, I just wish they would complete it a bit more. I would love to see const methods (as C++ does), multiple inheritence, static interface definitions, compiler enforced exception declarations (ala, Java) and a few other small features here and there. .... oh yea, and "WithEvents" should be part of C#! - Shame on them for forcing their horrible event syntax on me when VB.Net makes it so easy! (while I'm wishing, I wish I didn't have to type the stupid class name 50 times just to declare a class, and create a constructor or two. I mean, really, why all the redundancy with naming? There's gotta be a better syntax for this out there somewhere...) I mean, how silly is: public class Foo { Foo(){} Foo(int x){Foo()} Foo(int x, int y){Foo(x)} } Whew. I feel better now. :) -- Show quoteChris Mullins "Chris Saunders" <e***@mountaincable.net> wrote in message news:eBW4PCdvGHA.4384@TK2MSFTNGP04.phx.gbl... > Seems that you want programming by contract and multiple inheritance - how > about Eiffel? > > Regards > Chris Saunders > > "Chris Mullins" <cmull***@yahoo.com> wrote in message > news:uiEijVavGHA.3936@TK2MSFTNGP04.phx.gbl... >> "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote >>> >>> "Chris Mullins" <cmull***@yahoo.com> wrote >> >>>>I tend to build high performance system, and when doing this stateless >>>>programming is at a premium. This often means all of the public methods >>>>on a class are defined as static. >> >>>> Anyone have any suggestions of a solid way to do contract based >>>> development and still enforce statless programming? >> >>> Singletons and Factory methods. >> >> While these are two common patterns, neither one really solves the >> underlying problem. >> >> There's no way in code to say, "Any class that implementes this interface >> must be a singleton". Even if you could, everything ends up looking like, >> "MyClass.Instance.GetData", which is hardly idea. While I love the >> pattern and have used it quite a bit, it's not quite what I'm looking >> for. >> >> Static Factory Methods miss out on the Contract portion - there's no way >> to enfore the contracts. If an Interface provided for static methods, but >> without that.... >> >> -- >> Chris Mullins >> > > Just to let you know - Eiffel has the option for using .NET but it is not
required. Most Eiffel compilers compile to C code and then require another compiler to finish up. The company that produces the most popular (I believe) Eiffel compiler is located in Santa Barbara, but I don't believe Eiffel was invented there. I'm not a salesperson or otherwise a representative of Eiffel products but I would suggest you may want to have a closer look. This is a C# group so I'll say no more. Regards Chris Saunders Show quote "Chris Mullins" <cmull***@yahoo.com> wrote in message news:uIeLYXdvGHA.4972@TK2MSFTNGP05.phx.gbl... > It's not really Multiple Inheritence that I'm looking for (although that > would be nice, and I miss it from my C++ days), but the ability to have > static methods in the inheritence tree. > > I want, specifically, a way to say, "This method is stateless", and have > that enforced by a base class or an Interface. Right now the only way to > enfore that it to put the static keyword on a method - but there's no good > way to broadly enfore this at the architecture level. It would be nice, > while I'm wishing, to have overridable static members on a base class as > well. > > I looked into Eiffel a while ago - I lived in Santa Barbara, and the > language was invented there so I ended up at several presentations put on > about it. At the time, Eiffel was running atop the .Net CLR, which means > it can't really have the funcationality I'm looking for, as (to the best > of my knowledge) the CLR doesn't support what I'm describing. > > I'm happy with C#, I just wish they would complete it a bit more. I would > love to see const methods (as C++ does), multiple inheritence, static > interface definitions, compiler enforced exception declarations (ala, > Java) and a few other small features here and there. > > ... oh yea, and "WithEvents" should be part of C#! - Shame on them for > forcing their horrible event syntax on me when VB.Net makes it so easy! > > (while I'm wishing, I wish I didn't have to type the stupid class name 50 > times just to declare a class, and create a constructor or two. I mean, > really, why all the redundancy with naming? There's gotta be a better > syntax for this out there somewhere...) > > I mean, how silly is: > public class Foo > { > Foo(){} > Foo(int x){Foo()} > Foo(int x, int y){Foo(x)} > } > > Whew. I feel better now. :) > > -- > Chris Mullins > > > > "Chris Saunders" <e***@mountaincable.net> wrote in message > news:eBW4PCdvGHA.4384@TK2MSFTNGP04.phx.gbl... >> Seems that you want programming by contract and multiple inheritance - >> how about Eiffel? >> >> Regards >> Chris Saunders >> >> "Chris Mullins" <cmull***@yahoo.com> wrote in message >> news:uiEijVavGHA.3936@TK2MSFTNGP04.phx.gbl... >>> "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote >>>> >>>> "Chris Mullins" <cmull***@yahoo.com> wrote >>> >>>>>I tend to build high performance system, and when doing this stateless >>>>>programming is at a premium. This often means all of the public methods >>>>>on a class are defined as static. >>> >>>>> Anyone have any suggestions of a solid way to do contract based >>>>> development and still enforce statless programming? >>> >>>> Singletons and Factory methods. >>> >>> While these are two common patterns, neither one really solves the >>> underlying problem. >>> >>> There's no way in code to say, "Any class that implementes this >>> interface must be a singleton". Even if you could, everything ends up >>> looking like, "MyClass.Instance.GetData", which is hardly idea. While I >>> love the pattern and have used it quite a bit, it's not quite what I'm >>> looking for. >>> >>> Static Factory Methods miss out on the Contract portion - there's no way >>> to enfore the contracts. If an Interface provided for static methods, >>> but without that.... >>> >>> -- >>> Chris Mullins >>> >> >> > > A humble question:
What are the barriers (for the language architects) that prevent "Static virtual table"? Wouldn't that enable static contracts and overrides? As the required here is much needed Chris Saunders wrote: Show quote > Just to let you know - Eiffel has the option for using .NET but it is not > required. > Most Eiffel compilers compile to C code and then require another compiler to > finish up. > > The company that produces the most popular (I believe) Eiffel compiler is > located in Santa Barbara, but I don't believe Eiffel was invented there. > > I'm not a salesperson or otherwise a representative of Eiffel products but I > would suggest you may want to have a closer look. This is a C# group so > I'll say no more. > > Regards > Chris Saunders > > "Chris Mullins" <cmull***@yahoo.com> wrote in message > news:uIeLYXdvGHA.4972@TK2MSFTNGP05.phx.gbl... > > It's not really Multiple Inheritence that I'm looking for (although that > > would be nice, and I miss it from my C++ days), but the ability to have > > static methods in the inheritence tree. > > > > I want, specifically, a way to say, "This method is stateless", and have > > that enforced by a base class or an Interface. Right now the only way to > > enfore that it to put the static keyword on a method - but there's no good > > way to broadly enfore this at the architecture level. It would be nice, > > while I'm wishing, to have overridable static members on a base class as > > well. > > > > I looked into Eiffel a while ago - I lived in Santa Barbara, and the > > language was invented there so I ended up at several presentations put on > > about it. At the time, Eiffel was running atop the .Net CLR, which means > > it can't really have the funcationality I'm looking for, as (to the best > > of my knowledge) the CLR doesn't support what I'm describing. > > > > I'm happy with C#, I just wish they would complete it a bit more. I would > > love to see const methods (as C++ does), multiple inheritence, static > > interface definitions, compiler enforced exception declarations (ala, > > Java) and a few other small features here and there. > > > > ... oh yea, and "WithEvents" should be part of C#! - Shame on them for > > forcing their horrible event syntax on me when VB.Net makes it so easy! > > > > (while I'm wishing, I wish I didn't have to type the stupid class name 50 > > times just to declare a class, and create a constructor or two. I mean, > > really, why all the redundancy with naming? There's gotta be a better > > syntax for this out there somewhere...) > > > > I mean, how silly is: > > public class Foo > > { > > Foo(){} > > Foo(int x){Foo()} > > Foo(int x, int y){Foo(x)} > > } > > > > Whew. I feel better now. :) > > > > -- > > Chris Mullins > > > > > > > > "Chris Saunders" <e***@mountaincable.net> wrote in message > > news:eBW4PCdvGHA.4384@TK2MSFTNGP04.phx.gbl... > >> Seems that you want programming by contract and multiple inheritance - > >> how about Eiffel? > >> > >> Regards > >> Chris Saunders > >> > >> "Chris Mullins" <cmull***@yahoo.com> wrote in message > >> news:uiEijVavGHA.3936@TK2MSFTNGP04.phx.gbl... > >>> "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote > >>>> > >>>> "Chris Mullins" <cmull***@yahoo.com> wrote > >>> > >>>>>I tend to build high performance system, and when doing this stateless > >>>>>programming is at a premium. This often means all of the public methods > >>>>>on a class are defined as static. > >>> > >>>>> Anyone have any suggestions of a solid way to do contract based > >>>>> development and still enforce statless programming? > >>> > >>>> Singletons and Factory methods. > >>> > >>> While these are two common patterns, neither one really solves the > >>> underlying problem. > >>> > >>> There's no way in code to say, "Any class that implementes this > >>> interface must be a singleton". Even if you could, everything ends up > >>> looking like, "MyClass.Instance.GetData", which is hardly idea. While I > >>> love the pattern and have used it quite a bit, it's not quite what I'm > >>> looking for. > >>> > >>> Static Factory Methods miss out on the Contract portion - there's no way > >>> to enfore the contracts. If an Interface provided for static methods, > >>> but without that.... > >>> > >>> -- > >>> Chris Mullins > >>> > >> > >> > > > > Chris it seems to me that you are NOT looking for the ability to put static
methods in an interface but you are looking for a method to mark a method as stateless. The fact that a method is static does not make it stateless. private static int count = 0; public static foo() { count++; Console.WriteLine(count); } This method is certainly not stateless. Getting back to the stateless issue C++ has a weak form of this in const. There is currently not such support in .NET but I believe that you could define this with Spec#. The ability to mark that a method is stateless (and therefore thread safe) has been on the wish list of many for a long time. As for the interface bit I would probably just use a factory (and have the factory just return the same instance every time) or you could go a more small talk route with a variable. ex: Context.Current.MySomethingHandler.Process(message); where MySomethingHandler is a static variable of the appropriate type. This really bypasses the need to have static members considerred for inheritance. While you can't (in any _major_ .NET laguage) make a singleton interface you can create an external factory that will handle it for you (i.e. the facotry handles an object of interface i and insures that only one is created) Cheers, Greg Show quote "Chris Mullins" <cmull***@yahoo.com> wrote in message news:uIeLYXdvGHA.4972@TK2MSFTNGP05.phx.gbl... > It's not really Multiple Inheritence that I'm looking for (although that > would be nice, and I miss it from my C++ days), but the ability to have > static methods in the inheritence tree. > > I want, specifically, a way to say, "This method is stateless", and have > that enforced by a base class or an Interface. Right now the only way to > enfore that it to put the static keyword on a method - but there's no good > way to broadly enfore this at the architecture level. It would be nice, > while I'm wishing, to have overridable static members on a base class as > well. > > I looked into Eiffel a while ago - I lived in Santa Barbara, and the > language was invented there so I ended up at several presentations put on > about it. At the time, Eiffel was running atop the .Net CLR, which means > it can't really have the funcationality I'm looking for, as (to the best > of my knowledge) the CLR doesn't support what I'm describing. > > I'm happy with C#, I just wish they would complete it a bit more. I would > love to see const methods (as C++ does), multiple inheritence, static > interface definitions, compiler enforced exception declarations (ala, > Java) and a few other small features here and there. > > ... oh yea, and "WithEvents" should be part of C#! - Shame on them for > forcing their horrible event syntax on me when VB.Net makes it so easy! > > (while I'm wishing, I wish I didn't have to type the stupid class name 50 > times just to declare a class, and create a constructor or two. I mean, > really, why all the redundancy with naming? There's gotta be a better > syntax for this out there somewhere...) > > I mean, how silly is: > public class Foo > { > Foo(){} > Foo(int x){Foo()} > Foo(int x, int y){Foo(x)} > } > > Whew. I feel better now. :) > > -- > Chris Mullins > > > > "Chris Saunders" <e***@mountaincable.net> wrote in message > news:eBW4PCdvGHA.4384@TK2MSFTNGP04.phx.gbl... >> Seems that you want programming by contract and multiple inheritance - >> how about Eiffel? >> >> Regards >> Chris Saunders >> >> "Chris Mullins" <cmull***@yahoo.com> wrote in message >> news:uiEijVavGHA.3936@TK2MSFTNGP04.phx.gbl... >>> "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote >>>> >>>> "Chris Mullins" <cmull***@yahoo.com> wrote >>> >>>>>I tend to build high performance system, and when doing this stateless >>>>>programming is at a premium. This often means all of the public methods >>>>>on a class are defined as static. >>> >>>>> Anyone have any suggestions of a solid way to do contract based >>>>> development and still enforce statless programming? >>> >>>> Singletons and Factory methods. >>> >>> While these are two common patterns, neither one really solves the >>> underlying problem. >>> >>> There's no way in code to say, "Any class that implementes this >>> interface must be a singleton". Even if you could, everything ends up >>> looking like, "MyClass.Instance.GetData", which is hardly idea. While I >>> love the pattern and have used it quite a bit, it's not quite what I'm >>> looking for. >>> >>> Static Factory Methods miss out on the Contract portion - there's no way >>> to enfore the contracts. If an Interface provided for static methods, >>> but without that.... >>> >>> -- >>> Chris Mullins >>> >> >> > > "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote Very true. I can (and do) write occasional static constructors, static > Chris it seems to me that you are NOT looking for the ability to put > static methods in an interface but you are looking for a method to mark a > method as stateless. The fact that a method is static does not make it > stateless. variables, and other stateless no-no's. For the most part through, static means something pretty close to stateless. > Getting back to the stateless issue C++ has a weak form of this in const. Yea, that's not quite what I'm looking for either though. I've done alot of C++ programming, and I do miss const and mutable in .Net, but I can get along without them. I do quite like readonly member variables, as they can only be written to in the constructor. > The ability to mark that a method is stateless (and therefore thread safe) I would certatinly like this, although I still want to have it enforced by > has been on the wish list of many for a long time. base classes and/or interface definitions. Ah well, perhaps C# 4.0 will have it... I believe the pool is up to $25 from the advanced dotnet group now for
someone to implement an FXCop rule to do this :) Cheers, Greg Show quote "Chris Mullins" <cmull***@yahoo.com> wrote in message news:uWDEVKOwGHA.4140@TK2MSFTNGP06.phx.gbl... > "Greg Young" <druckdruckREMOVEgo***@hotmail.com> wrote >> Chris it seems to me that you are NOT looking for the ability to put >> static methods in an interface but you are looking for a method to mark a >> method as stateless. The fact that a method is static does not make it >> stateless. > > Very true. I can (and do) write occasional static constructors, static > variables, and other stateless no-no's. > > For the most part through, static means something pretty close to > stateless. > > >> Getting back to the stateless issue C++ has a weak form of this in const. > > Yea, that's not quite what I'm looking for either though. I've done alot > of C++ programming, and I do miss const and mutable in .Net, but I can get > along without them. I do quite like readonly member variables, as they can > only be written to in the constructor. > >> The ability to mark that a method is stateless (and therefore thread >> safe) has been on the wish list of many for a long time. > > I would certatinly like this, although I still want to have it enforced by > base classes and/or interface definitions. > > Ah well, perhaps C# 4.0 will have it... > > -- > Chris Mullins, MCSD.Net, MCPD:Enterprise > http://www.coversant.net/blogs/cmullins > > > > On Tue, 15 Aug 2006 15:24:21 -0400, "Greg Young"
<druckdruckREMOVEgo***@hotmail.com> wrote: >Getting back to the stateless issue C++ has a weak form of this in const. Well, if you're being pedantic about "stateless" I would have to saythat C++ const is no such thing. It does not _modify_ a state but it can still _access_ a state. Since another function might modify that state while the const function is reading it, this also means that a const function is not per se thread-safe. On Fri, 11 Aug 2006 15:13:41 -0700, "Chris Mullins"
<cmull***@yahoo.com> wrote: >Anyone have any suggestions of a solid way to do contract based development Not really. I'm just defining instance methods and add a note to the>and still enforce statless programming? XML comments that the "this" instance should be ignored... that's about as good as it gets in C#.  |
|||||||||||||||||||||||
Other interesting topics