marcap@concour.CS.Concordia.CA (Marc Pawlowsky) (07/12/89)
Why is it not legal to redfine a constant feature??
My problem:
Class image export nb_directions ....
feature
nb_directions:INTEGER is 4;
Class hex_image export nb_directions ...
inherit image redefine nb_directions ....
feature
nb_directions:INTEGER is 6;
is an error on Pass 2
Constant feature may not be redefined: nb_directions
yet if I change the code so that in image
nb_directions:INTEGER is
do Result := 4 end;
and in hex_image
nb_directions:INTEGER is
do Result := 6 end;
the program compiles.
**************************************************************************
Why I believe this is wrong.
*************************************************************************
1. Using information sharing it is no buisness of the ancestors how a
value is calculated. So there is a consistency problem.
2. There is no reason why the redefinition should not be allowed. At all
times the constant value can have only one possibility. Is the trouble
that a procedure in the parents class might not work if a child calls
it with a constant redefined. If so that is a case where the child
whould redefine the routine.bertrand@eiffel.UUCP (Bertrand Meyer) (07/17/89)
From <976@clyde.Concordia.CA> by marcap@concour.CS.Concordia.CA (Marc Pawlowsky): > Why is it not legal to redefine a constant feature? > [The following produces a compilation error]: > > class IMAGE ... feature > nb_directions: INTEGER is 4; ... > > class HEX_IMAGE ... inherit > IMAGE redefine nb_directions .... > feature > nb_directions: INTEGER is 6; ... A constant attribute is what the name indicates: its value does not change, either in the class or in any descendant. Actually the same message contains the solution: > Yet if I change the code [as follows] the program compiles: > > in IMAGE: nb_directions: INTEGER is do Result := 4 end; > in HEX_IMAGE: nb_directions: INTEGER is do Result := 6 end; This is the appropriate way to go: in such a case, use a function. My only pet complaint is that constant attributes should be used in each class rather than the manifest constants 4 and 6. -- Bertrand Meyer bertrand@eiffel.com
jimp@asterix.UUCP (Jim Patterson) (07/18/89)
In article <976@clyde.Concordia.CA> marcap@concour.CS.Concordia.CA (Marc Pawlowsky) writes: >Why is it not legal to redfine a constant feature?? Theoretically, you should of course be able to redefine any kind of feature, even a CONSTANT feature. (Some might disagree, of course, arguing that "CONSTANT" means "HAS A SINGLE VALUE" and in your case it takes on different values in different contexts). Practically, there is a problem which comes down to the fact that Eiffel implements class definitions using C, and implements constant features (with the exception of String constant features) as C constants. As a result, if redefinitions were allowed they would only affect the class where the redefinition occurred or subclasses of that class. They would not affect parent classes. This would be permitting a redefinition which was not really a redefinition, since it would not affect previously defined routines that made reference to the constant. The restriction against redefinition is a compromise between run-time efficiency and theoretical cleanness and orthogonality. Just requiring that implementers redefine features where the constant feature is used is not a solution, since it leaves it up to the implementor to locate and redefine the routines. In fact, if you want you can do that now; just RENAME the constant feature, and then define a new constant feature with the same name as the old. Since you will be redefining all routines that reference the constant feature, it doesn't matter that the old and new feature aren't really the same (they just have the same name). Of course, the compiler will not help to locate those routines that reference the constant feature which you must change. The best approach is essentially that you described, which is to define a routine which returns a constant value. You can implement it a bit more efficiently if you make the routine a ONCE routine. This is more overhead than a constant feature, but gives you the flexibility of redefining it in different classes. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4