roosen@cstw56.prl.philips.nl (Monique Roosen) (06/06/90)
Is there anybody out there in Eiffel-land who knows how to extend
the Eiffel STRING class with a feature for example ,
Tail(s:String_ext):String_ext to class STRING_EXT
and still have the possibility for an assignment like
n:STRING_EXT ;
n := "TEST".
I always receive a message like
"STRING is not a descendant class of STRING_EXT".
Thanks in advance.
Moniquerick@tetrauk.UUCP (Rick Jones) (06/08/90)
In article <1713@prles2.prl.philips.nl> roosen@cst.philips.nl (Monique Roosen) writes: > >Is there anybody out there in Eiffel-land who knows how to extend >the Eiffel STRING class with a feature for example , > Tail(s:String_ext):String_ext to class STRING_EXT >and still have the possibility for an assignment like > n:STRING_EXT ; > n := "TEST". >I always receive a message like > "STRING is not a descendant class of STRING_EXT". > I think you'll find this comes into the category of "impossible". The assignment A := B is only legal if B is the same class as A, or a descendant of A. The problem with strings is that the Eiffel compiler has the class STRING built in to its idea of a string literal, and you can't change that. "TEST" is always treated as a STRING type, so your assignment is not legal. If you really want to do this, it seems one case where you have to go into the kernel library and add your feature directly to string.e. Anyone know any smarter solutions? -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp
stephan@eiffel.UUCP (Philippe Stephan) (06/09/90)
In article #869, Monique Roosen (roosen@cst.philips.nl) asks: > Is there anybody out there in Eiffel-land who knows how to extend > the Eiffel STRING class with a feature for example , > Tail(s:String_ext):String_ext to class STRING_EXT > and still have the possibility for an assignment like > n:STRING_EXT ; > n := "TEST". Among the non-acrobatic ways to solve your problem, I would advise: n.share ("TEST"); instead of the assignment, which is of course impossible here.
yost@esquire.UUCP (David A. Yost) (06/14/90)
In article <487@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >In article <1713@prles2.prl.philips.nl> roosen@cst.philips.nl (Monique Roosen) writes: >> >>Is there anybody out there in Eiffel-land who knows how to extend >>the Eiffel STRING class with a feature for example , >> Tail(s:String_ext):String_ext to class STRING_EXT >>and still have the possibility for an assignment like >> n:STRING_EXT ; >> n := "TEST". >>I always receive a message like >> "STRING is not a descendant class of STRING_EXT". >> > >I think you'll find this comes into the category of "impossible". > >The assignment A := B is only legal if B is the same class as A, or a >descendant of A. The problem with strings is that the Eiffel compiler has the >class STRING built in to its idea of a string literal, and you can't change >that. "TEST" is always treated as a STRING type, so your assignment is not >legal. > >If you really want to do this, it seems one case where you have to go into the >kernel library and add your feature directly to string.e. Anyone know any >smarter solutions? I think this is a really important problem. If a class XSTRING * is a descendent of STRING * has no additional data features over what the string class has * has an invariant that is not stronger than STRING then why not allow the special-case builtin language syntax for a STRING constant, i.e. a quoted string, wherever an entity of type XSTRING is allowed? STRING is a great example of a simple object for which there could be lots and lots of useful procedures and functions, that will never all be in one standard, ideal STRING class. Problem is, If I create a new class that inherits from STRING and implements the functions and procedures I need, I can't use entities of this new class where STRINGs are required. I think it would be better if the builtin STRING class had an absolute minimum set of features, and one could choose from an extendable set of equivalent string types that implemented various string operations. At present, one has two choices: * modify the STRING class itself * create a descendent that is not "first class", i.e. can't do everything a STRING can do. Now I'll start groping around in the dark. Maybe there should be some other mechanism that would be like a restricted form of inheritance, call it `enhancement'. Given a class B which is an enhanced form of A: * A and B have the same invariant * A and B have the same data features * entities of classes A and B are usable interchangeably. This functionality would permit one to create a new class B that is just like a class A but implements some functions and procedures that the implementer of the original class left out or forgot or misimplemented. Class B could even hide some of the exported features of A. An set of `equivalent' classes would be classes that were related by enhancement. If classes A and B are equivalent, then x: A; y: B; z: C; x.f is permitted as long as f is defined A or in only one of the other equivalent classes. If f is not defined in A but is defined in B and C, then there would need to be a syntax to specify which feature f to apply. I claim that this facility would preserve Bertrand's open-closed principle, and in fact make it easier to practice. The above is not intended to be a fully formed spec, just some troubling problems searching for the formulation of a solution. --dave yost yost@dpw.com or uunet!esquire!yost Please ignore the From or Reply-To fields above, if different.
yost@esquire.UUCP (David A. Yost) (06/15/90)
In article <2084@esquire.UUCP> yost@esquire.UUCP (I) write: >An set of `equivalent' classes would be classes that >were related by enhancement. If classes A and B are >equivalent, then > > x: A; > y: B; > z: C; > > x.f > >is permitted as long as f is defined A or in only one >of the other equivalent classes. This won't fly because if someone comes along and declares a class D with feature f, the code is no longer unambiguous. It's got to be something more like this: x.f is permitted, as usual, only if f is defined A. I also said this: > If f is not defined in A but is defined in B and C, > then there would need to be a syntax to specify which > feature f to apply. Which I now revise to: If f is defined in B (whether or not it is also defined in A or C) there would need to be a syntax for applying feature f of B to x. For example: x%B.f Maybe before you can use this syntax, you should have to declare somehow that you believe B to be equivalent to A. This proposal does feel a bit like type casting in C and C++, but I hasten to point out that it differs in that it is typesafe, and that it is similar only to a subset of the cases in which type casting is used. --dave yost yost@dpw.com or uunet!esquire!yost Please ignore the From or Reply-To fields above, if different.