Path: utzoo!dciem!nrcaer!sce!asterix!jimp
From: jimp@asterix.UUCP (Jim Patterson)
Newsgroups: comp.lang.eiffel
Subject: Re: redefining constant features
Message-ID: <6580@asterix.UUCP>
Date: 17 Jul 89 20:50:08 GMT
References: <976@clyde.Concordia.CA>
Reply-To: jimp@cognos.UUCP (Jim Patterson)
Organization: Cognos Inc., Ottawa, Canada
Lines: 42

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