axel@coma.uucp (Axel Mahler) (10/05/90)
I am wondering about the semantics of inheritance from generic classes. More precisely, it's the semantics of constrained genericity. Consider the following situation: class C [P : T1] This notation is not intended to resemble any existing programming language. I think some new version of Eiffel will (has already ?) introduce this notation for constrained genericity. The meaning is: declare a class C with a formal generic parameter P that is constrained to class T1, i.e. any actual parameter that will substitute P must be "kind-of" T1. Now let: class D [Q : T2] inherit C and finally: classdef E D[T3] The latter construct shall denote a generic instantiation of generic class D with T3 as actual parameter (yielding a "real" class E). Do you think, this scenario makes any sense ? How shall both constraints be interpreted ? I came up with the opinion that the described setup does make sense if one adds both constraints, i.e.: T3 is-subclass-of T1 AND T3 is-subclass-of T2 I had an argument with a couple of collegues the other day, who insisted that T2 should be a subclass of T1. One collegue proposed that the generic paramter lists of C and D should be semantically concatenated, so that in the case of the generic instantiation two actual paramter classes shall be provided: classdef E D[T1a, T2a] and T1a, and T2a satisfying the individual constraints of C and D respectively. Unfortunately, there are only few discussions of genericity and inheritance. What do you think ?? cheers, Axel Mahler -- =============================================================================== Axel Mahler, Tech.Univ. Berlin E-Mail: axel@coma.cs.tu-berlin.de (axel@db0tui62.bitnet)
sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/05/90)
In article <1994@opal.tubopal.UUCP> axel@coma.uucp (Axel Mahler) writes: >I am wondering about the semantics of inheritance from generic classes. >More precisely, it's the semantics of constrained genericity. Consider >the following situation: > > class C [P : T1] > ... >Now let: > > class D [Q : T2] inherit C > >and finally: > > classdef E D[T3] > >The latter construct shall denote a generic instantiation of generic class >D with T3 as actual parameter (yielding a "real" class E). > >Do you think, this scenario makes any sense ? How shall both constraints >be interpreted ? I came up with the opinion that the described setup >does make sense if one adds both constraints, i.e.: > > T3 is-subclass-of T1 AND T3 is-subclass-of T2 > >I had an argument with a couple of collegues the other day, who insisted >that T2 should be a subclass of T1. One collegue proposed that the >generic paramter lists of C and D should be semantically concatenated, so >that in the case of the generic instantiation two actual paramter classes >shall be provided: > > classdef E D[T1a, T2a] > >and T1a, and T2a satisfying the individual constraints of C and D >respectively. > ... A quick suggestion: Right, obviously an actual generic parameter corresponding to P must _somehow_ be given in order for E to be a "real" (not generic) class. Should this, i.e. the instantiation of C, then be a matter of the interface or the implementation of D? If we want inheritance to mean an "is-a" or at least "is-like" relationship, then I suppose the generic parameter of C belongs to the _interface_ of D. Then, for the appropriate instantiation classdef G C [T4] we know that an E is-a G. If the definition of D is as above, I certainly agree with the proposal of your last-mentioned colleague (two actual generic parameters); E according to your own definition would most naturally remain a _generic_ class. To achieve your purpose with only one generic parameter for E, why not write the definition of D thus: class D [Q : T2] inherit C [Q] As for whether T2 should then be a subclass of T1 or not, it is not a question of principles, only of pragmatics and taste. The requirements for allowable actual generic parameters wil be exactly the same in both cases. The subclassing requirement would make it easier for clients of D to see what is required (especially in a large inheritance hierarchy). Omitting it (as you suggested yourself) would probably facilitate the development and reuse of D's own code, as T2 could show only those assumptions on which it is based. If we regard inheritance just as an implementation technique, then there can be whatever mechanism for D to instantiate C with whatever generic parameter when it gets instantiated itself. But in that case, even the fact that D inherits C at all does not necessarily belong to the interface (external definition) of D. Second (or would they already be fifth?) opinions solicited. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)