Should certain abstract classes be instantiable?

[Justin Johansson]

Justin Johansson Wrote:

> Andrei Alexandrescu Wrote:
> 
> > Jarrett Billingsley wrote:
> > > On Thu, Oct 1, 2009 at 4:30 PM, Andrei Alexandrescu
> > > <SeeWebsiteForEmail at erdani.org> wrote:
> > >> Consider:
> > >>
> > >> class A {
> > >>    abstract void fun() {}
> > >> }
> > >>
> > >> The class defines a function that is at the same time abstract (so it
> > >> requires overriding in derivees) and has implementation.
> > >>
> > >> Currently the compiler disallows creation of objects of type A, although
> > >> technically that is feasible given that A defines the abstract method.
> > >>
> > >> Should A be instantiable? What designs would that help or hinder?
> > > 
> > > Uh... why?
> 
> > Because I want to give a good argument one way or another in TDPL. FWIW, 
> > "I can't imagine why you'd ever..." or "Never needed that" are not 
> > strong enough arguments.
> 
> > Andrei
> 
> 
> Fair enough, Andrei.  I'm trying hard with the following use case
> to demonstrate that instantiation of the abstract is possibly useful.
> 
> Hope this helps or leads to further insight.

Just in case I'm misunderstood .. I don't believe the concept is particularly useful; just that
Andrei was looking for some example, presumably to expand upon in TDPL, and my
sample was just an exploratory idea.

Obviously the sample that I dreamed up results in an infinite loop if the "abstract" base class value() method is actually called.

-- Justin