Question-

Why use 'abstract' on a class definition?  Why not make all classes abstract that have at least 1 abstract member?  This applies to the java, C#, and D languages.

When would you declare a class as 'abstract' that does not have any abstract members??  What would be the point of this?

I believe that allowing the developer to flag a class as 'abstract' is a mistake.  This allows for programming stupidity to occur.

For example:

// I'll just assume my C# syntax is the same as D syntax,
// as I am new to D and I don't know what the heck I'm doing!  ;)

public abstract class MyBaseClass
{
public void f() {}
public virtual void g() {}
public void h() {}
}

// Now, to be able to use 'MyBaseClass', I have to inherit from it
// BUT!!
// I really don't have to change or override anything!

public class MyRedundantClass : MyBaseClass {}

// Now I can instance an exact duplicate of MyBaseClass!


See this?  Why even allow this madness?  I say let the compiler decide whether the class should be abstract based on the class members!!

Who's with me???

-Sam
sam987883@yahoo.com

Sam wrote:
> Question-
> 
> Why use 'abstract' on a class definition?  Why not make all classes abstract
> that have at least 1 abstract member?  This applies to the java, C#, and D
> languages.

Actually a class with any 'abstract' members /is/ made abstract.  Making a class explicitly abstract does have a few uses.  One: super-parents. Aka, classes that are specifically meant to be subclassed and not used directly.  I think Mango has a few examples of this, or did at one time anyhow.  (Kris has done a lot of refactoring since I last took a deep look at the Mango code, so it may be different.)  Another: singletons. One method we've stumbled on for making singletons is to use this formula:

# public abstract class MySingleton { static:
#   // members
# }

The 'abstract' attribute prevents instantiation, and the 'static:' attribute makes all members static.  Its cute, neh?  There may be other examples I haven't thought of.

-- Chris Sauls

Ahhh yes!  You are right!  I have used it for classes that only house static methods!  My bad!

Hey, can you use the keyword 'static' like this:

class c
{
static:
int a;
string b;
}

If so, that would be sweet as static memebers usually should be grouped together for clarity.  I don't think this could be done in C++...

Another question- can this be done:

class c
{
public static:
int a;
string b;
}

Or:

class c
{
public:
static:
int a;
string b;
}

?


In article <d7311l$kkg$1@digitaldaemon.com>, Chris Sauls says...
>
>Sam wrote:
>> Question-
>> 
>> Why use 'abstract' on a class definition?  Why not make all classes abstract that have at least 1 abstract member?  This applies to the java, C#, and D languages.
>
>Actually a class with any 'abstract' members /is/ made abstract.  Making a class explicitly abstract does have a few uses.  One: super-parents. Aka, classes that are specifically meant to be subclassed and not used directly.  I think Mango has a few examples of this, or did at one time anyhow.  (Kris has done a lot of refactoring since I last took a deep look at the Mango code, so it may be different.)  Another: singletons. One method we've stumbled on for making singletons is to use this formula:
>
># public abstract class MySingleton { static:
>#   // members
># }
>
>The 'abstract' attribute prevents instantiation, and the 'static:' attribute makes all members static.  Its cute, neh?  There may be other examples I haven't thought of.
>
>-- Chris Sauls

Sam-
sam987883@yahoo.com

Sam wrote:
> If so, that would be sweet as static memebers usually should be grouped together
> for clarity.  I don't think this could be done in C++...
> 

In D all attributes of this kind can be used in three ways:
# // the once-off
# public int foo;
#
# // the block
# public {
#   int foo;
#   float bar;
# }
#
# // and the "forever" or "until a wall"
# public:
#   int foo;
#   float bar;

So you can group static members together by using a "static attribute block" like so:
# public class Foo {
#   static {
#     const int BAR = 42;
#   }
# }

-- Chris Sauls

Hey

This is an ABUSE of the 'abstract' keyword!!  An ABUSE I tell you!!!

Then why not apply the 'static' keyword to a class with no abstract members instead?  That to me would be more clear.  It would say to me "This class is intended to hold only static members".

Well that's my opinion!  I think using the 'abstract' keyword to prevent the class from being instanced is kind of a hack, if you are going to use the class to hold only factory methods and do not intend for people to derive from it anyway.

Why not make the 'static' keyword apply to a class, forcing the class to not have a dynamic constructor/destructor or any dynamic members, not to be instantiable, and not to be inheritable?


In article <d7311l$kkg$1@digitaldaemon.com>, Chris Sauls says...
>
>Sam wrote:
>> Question-
>> 
>> Why use 'abstract' on a class definition?  Why not make all classes abstract that have at least 1 abstract member?  This applies to the java, C#, and D languages.
>
>Actually a class with any 'abstract' members /is/ made abstract.  Making a class explicitly abstract does have a few uses.  One: super-parents. Aka, classes that are specifically meant to be subclassed and not used directly.  I think Mango has a few examples of this, or did at one time anyhow.  (Kris has done a lot of refactoring since I last took a deep look at the Mango code, so it may be different.)  Another: singletons. One method we've stumbled on for making singletons is to use this formula:
>
># public abstract class MySingleton { static:
>#   // members
># }
>
>The 'abstract' attribute prevents instantiation, and the 'static:' attribute makes all members static.  Its cute, neh?  There may be other examples I haven't thought of.
>
>-- Chris Sauls

Sam-
sam987883@yahoo.com

On Thu, 26 May 2005 00:09:39 +0000 (UTC), Sam wrote:

> Hey
> 
> This is an ABUSE of the 'abstract' keyword!!  An ABUSE I tell you!!!

Well it might be in C++, and I don't claim to know about that. But in D, it is precisely correct.

In D, (which is not C++), 'abstract' means this and only this ...

When applied to a class definition, it means that the class can never be explicitly instantiated. That's it. No more and no less.

The purpose of abstract classes is to define a sort of template that can be used to create non-abstract classes. Typically, they hold abstract functions or 'default' behaviour functions.

> Then why not apply the 'static' keyword to a class with no abstract members instead?  That to me would be more clear.  It would say to me "This class is intended to hold only static members".

In D, (which is not C++), 'static' means this and only this ...

It is only used for functions and data, and it means that those items 'belong' to the class (or module) and not to specific instances of the class.

So to have an abstract class with static members makes sense. It defines a class which you can't create instances of and that has members that belong to the class. In other words, a 'singleton'.

> Well that's my opinion!  I think using the 'abstract' keyword to prevent the class from being instanced is kind of a hack, if you are going to use the class to hold only factory methods and do not intend for people to derive from it anyway.

Repeat after me ... " 'D' is not 'C++' ".

> Why not make the 'static' keyword apply to a class, forcing the class to not have a dynamic constructor/destructor or any dynamic members, not to be instantiable, and not to be inheritable?

Are you saying that if we code "static class Foo { ... }" that all its members would be static? We can do that now with this syntax ...

  class Foo { static { . . . }  }


-- 
Derek
Melbourne, Australia
26/05/2005 10:29:20 AM

In C++ static methods and static variables for that matter could reside at the namespace level (even under the global namespace!) so developers didn't have to worry about people misusing their containing class.

But with these newer languages like java, .NET, and D, all methods and variables
must reside in a class.
I have no problem with that!
But I have written hundreds of factory classes in all languages C++, C#, VB.NET,
and java (not in D yet though), and these classes are not intended to be
instanced nor inherited.  They are just suppose to act like a namespace
container for static-only methods.

So how to ensure a class will not be instanced or inherited from or otherwise misused?

Here's what I do (only in .NET and java as C++ allows me to put static stuff
under a namespace), I create a non-inheritable class by using a special keyword
attribute (final in java, sealed in C#, NotInheritable in VB.NET).  Does D have
a keyword like this?
After I create a non-inheritable class, I implement the compiler generated
constructors (default and copy constructors) as private.  This prevents
instantiation!  Mission accomplished!

But look at all the trouble I had to go through to accomplish this!!  D is new language; rather than behaving like java or C#, why not address these design pattern related issues?

True senior-level developers find they rely heavily on design patterns.  It would be nice if we had a language that was not only object-oriented, but design pattern based or at least design pattern friendly.

Let's make the D stand for Design patterns!

Seriously I never knew this language existed until this morning!

Well that's not entirely true, I read an article on D in some software journal several years ago!


In article <mn22e8n0ct4a.1k4ndbbbbpy4s.dlg@40tude.net>, Derek Parnell says...
>
>On Thu, 26 May 2005 00:09:39 +0000 (UTC), Sam wrote:
>
>> Hey
>> 
>> This is an ABUSE of the 'abstract' keyword!!  An ABUSE I tell you!!!
>
>Well it might be in C++, and I don't claim to know about that. But in D, it is precisely correct.
>
>In D, (which is not C++), 'abstract' means this and only this ...
>
>When applied to a class definition, it means that the class can never be explicitly instantiated. That's it. No more and no less.
>
>The purpose of abstract classes is to define a sort of template that can be used to create non-abstract classes. Typically, they hold abstract functions or 'default' behaviour functions.
>
>> Then why not apply the 'static' keyword to a class with no abstract members instead?  That to me would be more clear.  It would say to me "This class is intended to hold only static members".
>
>In D, (which is not C++), 'static' means this and only this ...
>
>It is only used for functions and data, and it means that those items 'belong' to the class (or module) and not to specific instances of the class.
>
>So to have an abstract class with static members makes sense. It defines a class which you can't create instances of and that has members that belong to the class. In other words, a 'singleton'.
>
>> Well that's my opinion!  I think using the 'abstract' keyword to prevent the class from being instanced is kind of a hack, if you are going to use the class to hold only factory methods and do not intend for people to derive from it anyway.
>
>Repeat after me ... " 'D' is not 'C++' ".
>
>> Why not make the 'static' keyword apply to a class, forcing the class to not have a dynamic constructor/destructor or any dynamic members, not to be instantiable, and not to be inheritable?
>
>Are you saying that if we code "static class Foo { ... }" that all its members would be static? We can do that now with this syntax ...
>
>  class Foo { static { . . . }  }
>
>
>-- 
>Derek
>Melbourne, Australia
>26/05/2005 10:29:20 AM

Sam-
sam987883@yahoo.com

On Thu, 26 May 2005 02:12:14 +0000 (UTC), Sam wrote:

> In C++ static methods and static variables for that matter could reside at the namespace level (even under the global namespace!) so developers didn't have to worry about people misusing their containing class.
> 
> But with these newer languages like java, .NET, and D, all methods and variables
> must reside in a class.
> I have no problem with that!

Actually, in D, it is possible to have 'free' methods and variables. These are members that are bound to a module and not a class. A module is simply a source file in D. A module can contain zero or more classes, plus zero or more free members. All free members in a module only exist once in the application. There is a special module 'constructor' and 'destructor' methods that is executed before main() is called and after main() exits, respectively.

> But I have written hundreds of factory classes in all languages C++, C#, VB.NET, and java (not in D yet though), and these classes are not intended to be instanced nor inherited.  They are just suppose to act like a namespace container for static-only methods.
> 
> So how to ensure a class will not be instanced or inherited from or otherwise misused?
> 
> Here's what I do (only in .NET and java as C++ allows me to put static stuff under a namespace), I create a non-inheritable class by using a special keyword attribute (final in java, sealed in C#, NotInheritable in VB.NET).  Does D have a keyword like this?

No. All classes are inheritable, though you can specify any of its methods to be non-overridable.

> After I create a non-inheritable class, I implement the compiler generated constructors (default and copy constructors) as private.  This prevents instantiation!  Mission accomplished!
> 
> But look at all the trouble I had to go through to accomplish this!!  D is new language; rather than behaving like java or C#, why not address these design pattern related issues?
> 
> True senior-level developers find they rely heavily on design patterns.  It would be nice if we had a language that was not only object-oriented, but design pattern based or at least design pattern friendly.
> 
> Let's make the D stand for Design patterns!

Not a bad idea ... but may be we wait until after v1.0 is released ;-)

> Seriously I never knew this language existed until this morning!
> 
> Well that's not entirely true, I read an article on D in some software journal several years ago!

It is still to reach v1.0 and thus 'mainstream' publicity.

-- 
Derek
Melbourne, Australia
26/05/2005 12:46:36 PM

Sam wrote:
> Question-
> 
> Why use 'abstract' on a class definition?  Why not make all classes abstract
> that have at least 1 abstract member?  This applies to the java, C#, and D
> languages.

An example of how I have used abstract classes with no abstract methods in Java: custom exception heirarchies. If I'm putting together a sizeable library (let's call it MyLib), I'll usually define a couple of  common base exception classes (MyLibException and MyLibRuntimeException) that all of my custom exceptions will derive from. I don't care if the runtime exception is instantiated and thrown, because the intent is to let it pass up to the top level and halt the program anyway. But, I don't want to be creating instances of MyLibException because it is not context specific. To reduce the temptation of doing so and to encourage the creation and use of more context-specific subclasses, I'll make MyLibException abstract. I could also just give it protected constructors, but it's the same thing either way.

It's also useful for implementing the Template Method design pattern. Consider this:

class MyBase
{
   public final void someAlgo()
   {
      doStepOne();
      doStepTwo();
      doStepThree();
   }
   protected abstract void doStepOne();
   protected abstract void doStepTwo();
   protected abstract void doStepThree();
}

The intent here is to let the subclass implement one or more of the step methods. But what if you want to provide a default implementation of each step, while still preventing MyBase from being instantiated? What if there are several steps that are the same for many subclasses? You could make a new subclass that derives from my MyBase and implements the abstract methods. Or, you could declare MyBase as abstract and implement the step methods directly.

I could cite a few more cases. IMO, declaring a class abstract with no abstract methods is a way to clearly communicate the intent behind a design. Both of the above cases have alternative implementations, but in  both cases I prefer the abstract class approach.

Sam wrote:
> Question-
> 
> Why use 'abstract' on a class definition?  Why not make all classes abstract
> that have at least 1 abstract member?  This applies to the java, C#, and D
> languages.
> 
> When would you declare a class as 'abstract' that does not have any abstract
> members??  What would be the point of this?
> 
> I believe that allowing the developer to flag a class as 'abstract' is a
> mistake.  This allows for programming stupidity to occur.
> 
> For example:
> 
> // I'll just assume my C# syntax is the same as D syntax,
> // as I am new to D and I don't know what the heck I'm doing!  ;)
> 
> public abstract class MyBaseClass
> {
> public void f() {}
> public virtual void g() {}
> public void h() {}
> }
> 
> // Now, to be able to use 'MyBaseClass', I have to inherit from it
> // BUT!!
> // I really don't have to change or override anything!
> 
> public class MyRedundantClass : MyBaseClass {}
> 
> // Now I can instance an exact duplicate of MyBaseClass!
> 
> 
> See this?  Why even allow this madness?  I say let the compiler decide whether
> the class should be abstract based on the class members!!
> 
> Who's with me???
> 
> -Sam
> sam987883@yahoo.com

Well, I can think of a case where an abstract class has no abstract methods ..

Suppose you are designing a system, where you have a design basically at the abstract level, and you intend to make several implementations through inheritnce and polymorphism: i.e. by subclassing the existing classes.

It may often come up that a component in the design is just a very abstract concept with no way to describe it, or with no common features that the possible subclasses share.

An example of this would be a "renderable" object in a virtual game engine. this "renderable" object might be anything, a "character" in a console (ascii graphics) game, a 2D image in a typical windows 2D game (that uses GDI), and it maybe something else in a 2D game that uses OpenGL (I don't know .. just saying maybe).

But still, the existance of this Renderable class is essential for the engine, so you want to write it.

You may be able to come up with some common features for all kinds of renderable objects, but what if these common features are always the same, and you never need to make any method abstract?

In this case, I wouldn't want anyone to instantiate this renderable class, because it's meaningless at this abstract level; it IS an abstract class with no abstract method, and it makes perfect sense to mark it "abstract" even though it contains no abstract methods.

Of course, various implementations (i.e. subclasses of other parts of the engine) will have to cast objects of this class to what the implementation expects.

The bottom line is: you would mark a class-with-no-abstrac-methods as abstract when it's only a represntation of an abstract idea, but it just happened to have no abstract methods.. and it's intended to be subclassed.
I think this is quite common and/or possible.