jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) (03/29/89)
In article <1463@gazette.bcm.tmc.edu> thomas@falcon.bcm.tmc.edu () writes: >by actual users. Jellinghaus says: >>I would like to extend the constrained-genericity >>mechanism to enforce the relations between my classes... is there any way >>to do this? Or should I redesign my class structure? >and my impression is that Eiffel will not enforce in the manner he is >proposing, and that one 'solution' to the CA inheritance problem is >to change the class structure such that: >rather than CA_CELL and CA_ACTION being 'siblings' of CA_LOCATION, >make one the child of the other, thus ensuring they both inherit from >the same CA_LOCATION. I considered this scheme too, but it won't work for one very simple reason: CA_LOCATION, CA_CELL, and CA_ACTION are all *deferred* classes. Each particular CA will define new classes (say, CONWAY_LOC, CONWAY_CELL, CONWAY_ACTION) which inherit from these deferred classes. This is the only way to make deferred classes useful (inherit from them and implement the features they describe). Now do you see why your proposal will not work? If I have CA_CELL inheriting from CA_LOCATION, I must create a CONWAY_CELL that implements all the features of *both* CA_LOCATION and CA_CELL. I can create a CONWAY_LOCATION inheriting from CA_LOCATION, but from what does CONWAY_CELL then inherit? From both CA_CELL and CONWAY_LOCATION? How would Eiffel resolve the repeated inheritance? The structure would look like this (_underlined_ classes are deferred): CONWAY_LOCATION / \ _CA_LOCATION_ CONWAY_CELL \ / _CA_CELL_------ And the structure gets even more ridiculous if the deferred class CA_ACTION inherits from the deferred class CA_CELL; there is still *no* way to guarantee that both CONWAY_ACTION and CONWAY_CELL, inheriting from CA_ACTION and CA_CELL respectively, both also inherit from CONWAY_LOCATION. Which is of course exactly what I want to happen... >Assume CA_ACTION inherits from CA_CELL. This might >involve resolving name-clashes of features to guarantee that CA_ACTION >does not use unwanted features from CA_CELL. Of course, CA_ACTION will be As you can see, the issue is somewhat more complex, and I'm bound to say I will probably do my own policing, by documenting the required inheritance structure. My scheme will look like this: _CA_LOCATION _CA_CELL_ \ >CONWAY_CELL CONWAY_LOCATION >CONWAY_ACTION _CA_ACTION_ The ">"s denote multiple inheritance. >I'd like to heara reply to all the issues jellinghaus has posted, >from Interactive Software Engineering (Meyer)... I would, too. Although after writing this posting, it begins to seem as though the language features I'm requesting are rather esoteric, and perhaps of only limited applicability; nevertheless, it does seem as though the constrained genericity mechanism needs expansion and clarification. And there should be a way to specify that a particular generic type *must* inherit from perhaps more than one type; the present scheme only lets you specify one required ancestor class... (Sorry if I missed any discussion on this topic; I was on break and a week of postings expired. Is this group archived anywhere?) Rob Jellinghaus | "Next time you see a lie being spread or a jellinghaus-robert@CS.Yale.EDU | bad decision being made out of sheer ignor- ROBERTJ@{yalecs,yalevm}.BITNET | ance, pause, and think of hypertext." {everyone}!decvax!yale!robertj | -- K. Eric Drexler, _Engines of Creation_