Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: >this< as a reference Message-ID: Date: 26 Oct 90 01:58:00 GMT References: <2058@aber-cs.UUCP> <58470@microsoft.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 122 In-reply-to: jimad@microsoft.UUCP's message of 22 Oct 90 23:08:16 GMT In article <58470@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: jimad> In article <2058@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> In article <58304@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: pcg> This looks very bizarre to me. Are you under the impression that pcg> references are kind of like pointers? I do not think so. I think pcg> they are very different. I guess that the new operator should pcg> continue to return pointers even if there are rerefences around. jimad> References are kind of like pointers, in that in common use both jimad> allow a way to access and send messages to objects: jimad> object.doSomething(); // verses: jimad> object->doSomething(); Well, you can use . also to access members off an object value, not just a reference to it. Weak reason to say that referneces are kind of pointers. They are indeed completely different, because their algebra is completley different -- for example, as they are now, you cannot compare references for equality, but you can compare pointers for equality. Indeed, as they are now, there are no values of type 'TYPE &', while there are values of type 'TYPE *'. jimad> Not using references for everything has given C++ some indirect jimad> advantages, though. Most other OOPLs always access objects via jimad> reference, using reference semantics. pcg> Read "pointers" throughout... Of course C++ has the advantage that pcg> to define composite it can use contiguity and not just pointers. pcg> This is a *large* advantage, and makes it clear that things like pcg> derivation are only justified in the context of a pointer based OO pcg> language, which C++ is not. jimad> Hm, I don't get this, you say that contiguity is a great jimad> advantage, but then state [without justification] that derivation jimad> is only justified in the context of a pointer based OO langauge, jimad> which C++ is not. So you seem to be stating that you think jimad> contiguity is good, but prohibits derivation? Can you explain jimad> this position? Ok, here we go: derivation in the form of prefixing was invented in Simula 67. Simula 67 was designed to be strictly Algol 60 compatible. To achieve this a decision was made to have an obviously distinct syntax and implementation for the bolted on OO aspects. Thus the decision to declare all objects using the ref(TYPE) syntax. This decision was probably justified but had two regrettable consequences, or maybe design goals: 1) pointers are in effect only introduced in the OO part of the language. The Algol 60 part stays pointerless. 2) not only pointers can only point only to objects, all objects can accessed only thru pointers. 3) all objects must live on the heap. All these are consequences of the desire to have Simula 67 as a very strict extension to Algol 60, which has neither pointers, not composition nor a heap; the base language is left unchanged. They need not apply to languages not based on Algol 60. For example C++ is based on C, which being a descendant of Algol 68 in many way, already has structures, pointers, and the heap as well as the stack. Now, in an OO language like Simula 67 (or Smalltalk or Eiffel, but these do not have the excuse of being based on Algol 60 and designed for strict orthogonality of extension to it) where all objects must be accessed via pointers creating composite objects can be inefficient, because it implies a pointer and indirection for each subobject (not a problem for Lispers of course :->). Thus Simula 67 prefixing, which allows physical contiguity of the fields of the subobjects. Unfortunately derivation as prefixing has also been given as a regrettable bonus an effect in the algebra of the interfaces of the classes involved, not just in their implementation -- not only is their representation merged, but also their interface, i.e. accessor functions and operations. This is regrettable, because it confuses the algebra of interfaces with that of implementations, binding the two so strictly. In C++ we have a looser and better, but not yet optimal, situation. We can have normal composition, that implies merging of implementation but not of interface, and derivation, in which both are merged. I have already argued in other articles that the algebras of implementations and interfaces should be strictly distinct. In particular I do not like derivation because it ties the merging of interfaces with the merging of implementations, while IMNHO we can find more interesting mechanisms for merging of implementations. For example, delegation in one form or another, does achieve merging of interfaces without requiring merging the implementations. In Simula 67 prefixing can be grudgingly accepted because there is no other way to have contiguity, given that the OO part of the language is strictly pointer based to differentiate it from the Algol 60 part. This is no longer true in C++, which is based on C, and where not only C is not as limited as Algol 60, but also strict extensioning is not a goal. Yet we still have to use prefixing for merging interfaces, but it is plain to the naked eye that it is a rotten technology (complexities abound), and there is no need to tie it with contiguity and viceversa. jimad> I do not define primitive as non-composite, but rather classes that are jimad> relativily simple and follow value semantics, rather than reference semantics. This is self-serving... Uhm. jimad> Experience with Algol may help one understand C++ references, but it in jimad> no way helps one remember which of the . or -> syntax one needs to use when jimad> dealing with someone else's classes, nor whether a reference or a pointer is jimad> expected as a parameter, or is returned from a routine, or ....: This si only because the C++ references were added as an aftethought. If C had been designed along the Algol 68 lines, with a unified concept of references, and a clear distinction between object values and reference values, there would be no such problems. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk