Thank you everyone for your contributions to this discussion. I'm enjoying the various spin-offs. I've chosen a few statements to respond to that fit the context in my head on wider related issues (I hope you collectively don't mind).
> [Gregory Young] use a singleton pattern to get around this. Yes indeed, the singleton pattern is the way to go for this. In one way, I see static (not that I am asserting this as correct) as the "poor man's singleton", but I'll elaborate that in a bit. > [Gregory Young] interfaces need an instance... > [Steve Johnson] A class is the blueprint for an object and an object > is an instance of a class. You have no objects w/o instances; only > blueprints for the creation of objects. At least in once sense, there are instances of static classes, only that these instances are restricted to a single instance on a per-process basis. I've always thought of the static keyword as process-scoping attribute: specifically that it scopes instance-ness of the thing to which it is applied (a class in this case). In an N-process environment (we could probably [though I don't know a huge amount about this] substitute AppDomain for process) I can have N instances of my static class (and the members contained within them). Now, in the current instantiation of the .net framework, we don't have easy access to these instances and I'll agree that it breaks the paradigm to think this way but we *could* hack-fest away to make it a reality. A large part of my distinction between objects (type instances) and definitions (types) is whether state is contained (e.g. instantiated member variables). Within this understanding, at run-time a static class, especially the kind that I started this out with, fits better into the object category than the definition category. I'm not opposed to the notion that I'm entirely mislead. To wax on a bit, what I've seen is that through standard language capabilities in combination with technologies like COM, Remoting, Webservices, we've provided ourselves with various means of scoping objects to objects, methods, threads, processes, machines, domains, etc. but to my knowledge, there has never been an integrated object instance scoping attribute that crosses the boundaries. What would be really nice to have would be something like [InstanceScope( InstanceScopeType.Process )] as a replacement to the static key word. Arguably, this might more appropriately be applied to an instance... Thanks, Erik Erikson -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of gregory young Sent: Thursday, May 24, 2007 7:53 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: static class interface How would you pass it? interfaces need an instance... use a singleton pattern to get around this. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
