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.

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 MCSD.Net, MCPD Enterprise
http://www.coversant.net/blogs/cmullins

"Chris Mullins" <cmullins (AT) yahoo (DOT) com> wrote


Singletons and Factory methods.

David

"David Browne" <davidbaxterbrowne no potted meat (AT) hotmail (DOT) com> wrote
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

Seems that you want programming by contract and multiple inheritance - how
about Eiffel?

Regards
Chris Saunders

"Chris Mullins" <cmullins (AT) yahoo (DOT) com> wrote

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" <evas (AT) mountaincable (DOT) net> wrote

On Fri, 11 Aug 2006 15:13:41 -0700, "Chris Mullins"
<cmullins (AT) yahoo (DOT) com> wrote:

Not really. I'm just defining instance methods and add a note to the
XML comments that the "this" instance should be ignored... that's
about as good as it gets in C#.
--
http://www.kynosarges.de

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" <cmullins (AT) yahoo (DOT) com> wrote

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:

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

"Chris Mullins" <cmullins (AT) yahoo (DOT) com> wrote

"Greg Young" <druckdruckREMOVEgoose (AT) hotmail (DOT) com> wrote
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.


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.

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