🚀 go-pugleaf

In article <1993Jan5.222300.29535@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>In article <1993Jan5.060332.5262@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>|> 	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.
>|> 
>
>
>I completely disagree with the premise. 

	Fair enough. If you want subobjects to be counted
as objects, you must!

>Maybe we are using 
>"object" in different senses.  An important "attribute" of
>an object (defined as a region of storage by both the C 
>standard and the ARM) is its relationship to other regions
>of storage.

	Maybe we are using "attribute" in different senses.
For me an attribute is a function returning boolean with
one argument.

	A relation returns boolean and has two arguments,
and it is not an attribute: an attribute is an intrinsic
property, needing no reference to the outside world
or other thing for its evaluation.
>
>To take a simple example
>
>	int a[10];
>
>It is an important attribute of a[2] that it is the 3rd
>subobject of a 10 element array.  

	It is a relation between a and a[2] at best.
>
>struct S { int i ; int j ; } s ;
>
>It is an important attribute of s.j that it is the "j" subobject
>of s.   

	A relation. Not a property of 's.j' which as an object
is merely an 'int'. Yes, as an object that 'int' has an address
distinct from other ints. Two different 'int's may have the same
value, and the same 'int' object may have different values
at different times.

	The address of the int object 's.j' is an attribute
of 's.j' as an object. Its relation as an object to 's'
is not an attribute of 's.j'.
>
>Perhaps you disagree that a[2] or s.j are "objects"?  

	No, I agree they are objects.

	I do not necessarily agree their relationship
to other objects is a property they possess as objects,
however. In fact, I might contend that maintaining
this is a violation of the notion of encapsulation.
An objects relation to some other object is an intrinsic
property of the object if, and only if, it contains
a pointer (or reference) to that other object.

	Otherwise it is a property of the system,
not the individual object.

>And a "base subobject" bears an analogous relationship to the
>containing object(s).  

	Not necessarily: contained objects are self contained.
Base subobjects are not always self contained: they are
never self contained if they have pure virtual members.
>
>|> 	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.
>
>The data members of a class are also subobjects according to
>my understanding.  You're even disallowing that?  

	No, the ARM is disallowing that if you require
object identity as a property of objects. That identity
being determined by pointer comparisons.

	Unless I missed something.

	class X {};
	class Y { X x1, x2; }

Nothing says &x1 != &x2. Perhaps it should. Perhaps I'm wrong.

>|> 	Is the issue not simple: either we waste bytes
>|> to obtain object identity for subobjects or we dont.
>|> 
>
>I can phrase begging questions too. Either we implement the
>language correctly or we fudge, save a byte and hope nobody
>notices. 

	Why is this a 'begging question'? That the bytes
would be wasted in some cases is beyond dispute.
Whether this is important for other than complete objects
I am not sure.

>
>Apparently the issue isn't simple.  There is a fundamental
>disagreement about the semantics of C++.  If that disagreement
>is resolved it will tell us what is a legal implementation.
>We can use the consequences for storage layout and sizes as
>a criterion for determining the semantics, but it can't be
>the sole criterion.
>
	As I said I am not sure which choice to make.
I did not intend to claim *making* the choice would be
easy, only that the alternatives are just TWO, and
both of them are well defined and understood.

	Am I wrong in this? Are there other alternatives?

[My claim is marginally non-trivial: I am disallowing wasting
bytes in included objects but optimising them away in base
subobjects. That would be a third option. But it seems
to me that that does not give proper object identity
semantics to pointer comparisons, and also wastes bytes.
So it is not a good option.]

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