www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - abstract on a class- redundant?

reply Sam <Sam_member pathlink.com> writes:
Question-

Why use 'abstract' on a class definition?  Why not make all classes abstract

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:


// 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
May 25 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Sam wrote:

 Question-
 
 Why use 'abstract' on a class definition?  Why not make all classes abstract

 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:





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
May 25 2005
next sibling parent reply Sam <Sam_member pathlink.com> writes:
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

 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:





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
May 25 2005
next sibling parent Chris Sauls <ibisbasenji gmail.com> writes:
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:














So you can group static members together by using a "static attribute 
block" like so:






-- Chris Sauls
May 25 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Sam wrote:

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


<snip top of upside-down reply>

Is there really any point in that?  D isn't Java.  D has modules for 
grouping functions together.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
May 27 2005
prev sibling parent reply Sam <Sam_member pathlink.com> writes:
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

 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:





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
May 25 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
May 25 2005
parent reply Sam <Sam_member pathlink.com> writes:
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!

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

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

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
May 25 2005
parent Derek Parnell <derek psych.ward> writes:
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. 



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

 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

 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
May 25 2005
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Sam wrote:

 Question-
 
 Why use 'abstract' on a class definition?  Why not make all classes abstract

 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.
May 26 2005
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Sam wrote:

 Question-
 
 Why use 'abstract' on a class definition?  Why not make all classes abstract

 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:
 

 // 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.
May 26 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Sam wrote:

 Question-
 
 Why use 'abstract' on a class definition?  Why not make all classes abstract

 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.


<snip>

It also enables code to be self-documenting.

Suppose you have a class that has lots of methods.  Some may be 
abstract.  But should one have to look through the class (and any 
superclasses) to check whether the class is abstract?  We might as well 
have this information at the beginning of the class definition itself.

It's true that you can stick a comment up there, but allowing the 
programmer to declare the class with the abstract attribute makes it 
more elegant.

This provides a neat means of setting a class to be abstract even if it 
has no abstract methods.  Even if we knew no use for this, to disallow 
it would be an arbitrary restriction, and so the notation has this 
by-product.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
May 27 2005