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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: jsa@organon.com (Jon S Anthony) Subject: Re: Choice of OO primitives in Ada95 Date: 1996/02/20 Message-ID: X-Deja-AN: 140329433 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-02-20T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > 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 ... > :> > :>... > :>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. What in this in anyway could even _possibly_ be construed in the course of even the most tortuous path of illogic to be saying _all_ the types _together_ need to be in the _same_ package? Hmmmmmm???? > 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). See above (possibly even more so). > Dispatching or not dispatching depending on where an operation is > defined is not what you would call consistent. Why not? Seems pretty simple really. And it allows for non dispatching operations to be constructed if they have a closer match to the desired semantics. And why should operations that are closely tied to the semantics of a type (basically the intent of primitive operations) be definable anywhere? That sort of thing leads pretty quickly to inscrutable structures. (I believe that Dylan does allow this sort of thing, but there has been disagreement on how "wonderful" it is.) > 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. Ahhh, the ol' clairvoyant compiler. You are on a roll. What if the type is not extended? This sort of comment might make sense if you were discussing a language where the only kinds of types available were "classes" (actually, it would not even make sense there as then it would be irrelevant). But you aren't. Of course you can decry this fact, but that is another matter altogether and irrelevant given the current context. Also, given the context, it is very much the case that "tagged" is _not_ simply an implementation issue. Flagging a particular type as one which is extensible and supportive of dynamic polymorphism can be argued to be a "good engineering" tradeoff. > 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. This is just plain wrong - on several accounts. First class wide operations do not dispatch (they have uses more akin to a "generic method" in CLOS, though clearly more restricted). Second, _all_ primitive operations are dispatching operations. The "developer" does _not_ specify that an operation dispatches (other than simply including it as a primitive operation of a tagged type). Third, optimization is irrelevant _to the semantics_ of whether any actual _invocation_ dispatches. Sans optimizations a primitive operation dispatches iff it has class-wide actuals for the operation's controlling parameters - the compiler _always_ knows when a particular call of an operation dispatches. Fourth, optimization is also (mostly) irrelevant for making the design choice of keeping instances of dynamic polymorphism a local rather than global issue. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com