dld@F.GP.CS.CMU.EDU (David Detlefs) (04/22/89)
I've just finished reading OOSC, and found it very interesting. If you believe in strong typing and inheritance, then, in my opinion, the most important remaining question on which there is reasonable disagreement is whether subclasses should have access to superclass implementations. I've tended towards the view that they shouldn't (or at least should be very careful when they do) based on arguments by Liskov, Snyder, and Stroustrup. Meyer makes a fairly strong case that I see as basically of the form "but if you allow it, look at all the neat things you can do!" And the things you can do are quite interesting. Having thrown in my capsule review, I have a question about Eiffel. Somewhere in the book there is reference to the "golden rule" of the Eiffel type system: on page 223, it says "Once a system has been compiled, there is no risk that a feature will ever be applied at run-time to an object that is not equipped to handle it." This is a laudable goal. My question is how this can be reconciled with the "orthoganility of information hiding" -- on page 272, we find that a descendant class B is allowed not to export to clients a feature f that its ancestor A does export. Now, if we have an entity x of static type A and dynamic type B, is x.f legal? If so, does this make sense, and why? It seems to me that if you create a B, allowing f to be invoked could violate B's representation invariant. (Consider a type A that is basically an integer. It is created with value 0, and offers "incr" and "incr_by_2" operations. Its rep invariant is that it is > 0. If B inherits from A, but only exports the create and incr_by_2, its invariant is that it is > 0 and divisible by 2. If you ever invoke incr on a B, you violate its invariant.) Can anyone clear this up for me? Thanks. Dave -- Dave Detlefs Any correlation between my employer's opinion Carnegie-Mellon CS and my own is statistical rather than causal, dld@cs.cmu.edu except in those cases where I have helped to form my employer's opinion. (Null disclaimer.) --
dcr0@bunny.UUCP (David Robbins) (04/24/89)
From article <DLD.89Apr21161427@F.GP.CS.CMU.EDU>, by dld@F.GP.CS.CMU.EDU (David Detlefs): > Somewhere in the book there is reference to the "golden rule" of the > Eiffel type system: on page 223, it says > > "Once a system has been compiled, there is no risk that a > feature will ever be applied at run-time to an object that is not > equipped to handle it." > > This is a laudable goal. My question is how this can be reconciled > with the "orthoganility of information hiding" -- on page 272, we find > that a descendant class B is allowed not to export to clients a > feature f that its ancestor A does export. Now, if we have an entity > x of static type A and dynamic type B, is x.f legal? If so, does > this make sense, and why? It seems to me that if you create a B, > allowing f to be invoked could violate B's representation invariant. > > (Consider a type A that is basically an integer. It is created with > value 0, and offers "incr" and "incr_by_2" operations. Its rep > invariant is that it is > 0. If B inherits from A, but only exports > the create and incr_by_2, its invariant is that it is > 0 and > divisible by 2. If you ever invoke incr on a B, you violate its invariant.) > > Can anyone clear this up for me? Thanks. Well, I'm not sure we can exactly clear this up, but I can shed a little light on the subject. There was some discussion related to this issue on the net a few weeks ago, and Bertrand Meyer pointed out that the current release of Eiffel (2.1 at the time) was in fact unable to properly enforce the "golden rule" in the particular circumstances you bring out. His clear intent was indeed that Eiffel should not permit the invocation, by a client, of an operation that was inherited but not exported. He also said that he was working on a technique whereby this restriction could be properly enforced by the compiler, but he gave no details. I don't recall whether proper detection of violations of this nature was promised for release 2.2 of Eiffel. I know from my own experiments that you could write a pair of Eiffel classes as you suggest, compile them without error, and invoke the incr operation on an instance of type B. Indeed, this can lead to undesirable behavior, and your only recourse is to carefully hand-check your program for violations of this nature. I look forward to the time when Eiffel can catch -- either at compile time or at run time -- violations of all of its rules. Perhaps someone else on the net can answer this more definitively than I can, but I hope this is of some help. -- Dave Robbins GTE Laboratories Incorporated drobbins@gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254
dcr0@bunny.UUCP (David Robbins) (04/24/89)
From article <DLD.89Apr21161427@F.GP.CS.CMU.EDU>, by dld@F.GP.CS.CMU.EDU (David Detlefs): > Somewhere in the book there is reference to the "golden rule" of the > Eiffel type system: on page 223, it says > > "Once a system has been compiled, there is no risk that a > feature will ever be applied at run-time to an object that is not > equipped to handle it." > > This is a laudable goal. My question is how this can be reconciled > with the "orthoganility of information hiding" -- on page 272, we find > that a descendant class B is allowed not to export to clients a > feature f that its ancestor A does export. Now, if we have an entity > x of static type A and dynamic type B, is x.f legal? If so, does > this make sense, and why? It seems to me that if you create a B, > allowing f to be invoked could violate B's representation invariant. > > (Consider a type A that is basically an integer. It is created with > value 0, and offers "incr" and "incr_by_2" operations. Its rep > invariant is that it is > 0. If B inherits from A, but only exports > the create and incr_by_2, its invariant is that it is > 0 and > divisible by 2. If you ever invoke incr on a B, you violate its invariant.) > > Can anyone clear this up for me? Thanks. Well, I'm not sure we can exactly clear this up, but I can shed a little light on the subject. There was some discussion related to this issue on the net a few weeks ago, and Bertrand Meyer pointed out that the current release of Eiffel (2.1 at the time) was in fact unable to properly enforce the "golden rule" in the particular circumstances you bring out. His clear intent was indeed that Eiffel should not permit the invocation, by a client, of an operation that was inherited but not exported. He also said that he was working on a technique whereby this restriction could be properly enforced by the compiler, but he gave no details. I don't recall whether proper detection of violations of this nature was promised for release 2.2 of Eiffel. I know from my own experiments that you could write a pair of Eiffel classes as you suggest, compile them without error, and invoke the incr operation on an instance of type B. Indeed, this can lead to undesirable behavior, and your only recourse is to carefully hand-check your program for violations of this nature. I look forward to the time when Eiffel can catch -- either at compile time or at run time -- violations of all of its rules. Perhaps someone else on the net can answer this more definitively than I can, but I hope this is of some help. From vn Mon Apr 24 09:47:27 1989 From vn Mon Apr 24 09:43:07 1989 Subject: Re: Typing question in eiffel Newsgroups: comp.lang.eiffel References: <DLD.89Apr21161427@F.GP.CS.CMU.EDU> From article <DLD.89Apr21161427@F.GP.CS.CMU.EDU>, by dld@F.GP.CS.CMU.EDU (David Detlefs): > Somewhere in the book there is reference to the "golden rule" of the > Eiffel type system: on page 223, it says > > "Once a system has been compiled, there is no risk that a > feature will ever be applied at run-time to an object that is not > equipped to handle it." > > This is a laudable goal. My question is how this can be reconciled > with the "orthoganility of information hiding" -- on page 272, we find > that a descendant class B is allowed not to export to clients a > feature f that its ancestor A does export. Now, if we have an entity > x of static type A and dynamic type B, is x.f legal? If so, does > this make sense, and why? It seems to me that if you create a B, > allowing f to be invoked could violate B's representation invariant. > > (Consider a type A that is basically an integer. It is created with > value 0, and offers "incr" and "incr_by_2" operations. Its rep > invariant is that it is > 0. If B inherits from A, but only exports > the create and incr_by_2, its invariant is that it is > 0 and > divisible by 2. If you ever invoke incr on a B, you violate its invariant.) > > Can anyone clear this up for me? Thanks. Well, I'm not sure we can exactly clear this up, but I can shed a little light on the subject. There was some discussion related to this issue on the net a few weeks ago, and Bertrand Meyer pointed out that the current release of Eiffel (2.1 at the time) was in fact unable to properly enforce the "golden rule" in the particular circumstances you bring out. His clear intent was indeed that Eiffel should not permit the invocation, by a client, of an operation that was inherited but not exported. He also said that he was working on a technique whereby this restriction could be properly enforced by the compiler, but he gave no details. I don't recall whether proper detection of violations of this nature was promised for release 2.2 of Eiffel. I know from my own experiments that you could write a pair of Eiffel classes as you suggest, compile them without error, and invoke the incr operation on an instance of type B. Indeed, this can lead to undesirable behavior, and your only recourse is to carefully hand-check your program for violations of this nature. I look forward to the time when Eiffel can catch -- either at compile time or at run time -- violations of all of its rules. Perhaps someone else on the net can answer this more definitively than I can, but I hope this is of some help. -- Dave Robbins GTE Laboratories Incorporated drobbins@gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254
dcr0@bunny.UUCP (David Robbins) (04/24/89)
Oops -- I had a strange interaction with my posting program, and somehow managed to post the same thing three times. I'm not at all sure how that happened, but my apologies for wasting net bandwidth.-- Dave Robbins GTE Laboratories Incorporated drobbins@gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254