🚀 go-pugleaf

In article <9300812.4038@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> maxtal>	One consequence: abstract objects can exist.
> maxtal>
> maxtal>	Corollary: such objects have states not accessible via
> maxtal>	the contiguous storage allocated for them.
> maxtal>	(via virtual function calls)
> 
> To me, an abstract class is a class without any actual objects of that class,
> so the idea of an "abstract object" seems to be an oxymoron. Similarly, the
> idea that an object can have "state" that is not stored in its "storage" seems
> to make a mockery of the whole idea of "storage".

Since John MAX Skaller was drawing inferences from my belief that base
class subobjects are objects, I want to go on record.  I agree that
"abstract objects" can exist, but the corollary does not follow.  

The easiest way to find an actual object of an abstract class is from
the point of view of a constructor for an abstract class.  What's the
type of the object pointed to by 'this'?  The type of that object is the
abstract class, no question about it.

In the corollary, John MAX Skaller is referring to a different scenario
in which the object of abstract class is a base class subobject of a
fully-constructed enclosing object.  He concludes that the state of the 
enclosing object is part of the state of the base class subobject.  The
reasoning has something to do with the additional state being accessible via
virtual function calls, but there's a big hole in it.  Virtual functions 
(and non-virtual functions) can access any number of other objects,
independent of the object for which they are called.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com