🚀 go-pugleaf

In article <1993Jan4.200625.5680@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <9300300.29980@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>|> 
>|> As I noted in a previous article, I don't agree with Scott Turners belief
>|> that base class subobjects are objects. To me, these are absurd 
>|> consequences, and thus I conclude that the assumption used in deriving them
>|> must be flawed.
>
>Perhaps fjh would specify some of these "absurd consequences".  I
>agree with Scott.  Base class subobjects are objects. Anything else 
>would be incomprehensible to me.

	If an 'object' is something whose attributes are computed
from its internal state, then clearly subobjects need not
be objects. In the sense an object is 'self contained',
an 'instance' of an abstract class cannot be an object.

	In particular, the semantics of a virtual function
in a subobject are not encapsulated in the subobject class
definition (especially for pure virtuals :-)

	I suspect that only 'complete objects' can really
qualify to be genuine, true blue objects. 
Which is not to say they shouldn't support object identity.
However the current rules do seem to provide object
identity --- if at all -- only for complete objects.

	Since the current system does not provide subobjects
with object identity, nor do subobjects enjoy the same
'completeness' properties of complete objects, it is difficult
to argue that because subobjects are objects they ought to
have all the properties of objects---the converse argument
that because subobjects dont have the properties of
objects, they aren't objects is equally compelling and
equally meaningful (or devoid of such).

	Is the issue not simple: either we waste bytes
to obtain object identity for subobjects or we dont.

If we do .. we waste bytes.

If we dont, then comparison of pointers in a subroutine

	f(X* x1, X* x2) { if(x1==x2) ... }

is reliable only if f is called with complete object pointers.
I.e.: there is a precondition, and one that might be hard for
the caller to ensure.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------