From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Choice of OO primitives in Ada95 Date: 1996/02/20 Message-ID: #1/1 X-Deja-AN: 140224195 sender: news@assip.csasyd.oz references: organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.ada Date: 1996-02-20T00:00:00+00:00 List-Id: Robert A Duff writes: :In article , :Don Harrison wrote: :>package X is :> type MARRIAGE is tagged ... :> type PERSON is tagged ... :> type UNIVERSITY is tagged ... :> type GOVERNMENT is tagged ... :> type ELECTORATE is tagged ... :> type ADDRESS is tagged ... :> :> procedure Enrol (Student : in out PERSON; Uni : in out UNIVERSITY); :> procedure Award_Grant (Polies : in out GOVERNMENT; Uni : in out UNIVERSITY); :> procedure Make_Gerrymander (Polies : in out GOVERNMENT; Elect : in out ELECTORATE); :> function Office_Address (Elect : in ELECTORATE) return ADDRESS; :> :>end X; :> :>Each abstraction is related to the previous one but isn't necessarily related :>to any other. As I understand it, the language rules dictate that each of these :>abstractions must be in the same package. : :No, they don't have to be in the same package (and as you say, probably :should not be). Could you explain what you mean -- why do you think :that all of the above types have to be in the same package? I don't have an RM available but quoting you (25.1.96) on the subject of dispatching operations in response to Arcadio A. Sincero: > >As a matter of fact, the only indication that TPerson's Walk "belongs to > >it" is that TPerson's Walk has a TPerson parameter. > That, plus the fact that it's in the same package. So, if you want all of the operations to be dispatching (primitive), then the tagged types must also be in the same package. In the same thread, Jon S Anthony went on to say that non-dispatching operations using tagged types were those defined in different packages to those types: > Just to add one more bit (completely beating it to death...), it is also > legal to have a subprogram with operands of both types as long as it is > not in the package where the two types are declared. Of course such a > subprogram is not primitive and will never dispatch (assuming it has no > other controlling operands). Dispatching or not dispatching depending on where an operation is defined is not what you would call consistent. A couple of other gripes: 1) Why should you have to specify that a type is 'tagged'? Can't the compiler work that out for itself? eg. by seeing whether the type is extended elsewhere. The developer is forced to worry about what should be an implementation issue. 2) Similarly, why should the developer have to specify that an operation dispatches (classwide operations)? Presumably, you're aiming for quicker execution, but compilers could perform a certain degree of optimisation eg. If it knows the type is not extended anywhere, there is no need to dispatch. There would also be situations where the specific variant of an inherited type is known eg. following an explicit assignment from an entity of that type. [...] :- Bob Don.