Hi Manu and Alexander.
I had seen the catcall problem threatening my approach. But this risk
already exists. By default.
local
cs: SET [COMPARABLE]
ss: SET [STRING]
do
create ss -- etc.
cs := ss -- SET [STRING] conforms(!) to SET [COMPARABLE]
cs.put (123) -- CATCALL!!!
...
Please have a look at my sample code in the original post of this
thread: I have taken care, by renaming and selecting, in order to
mitigate the risk of catcall. I said "mitigate" because in the current
state of Eiffel I simply don't know how to prevent it altogether.
My point is another. Let me try a simpler (I hope) example.
class ORDERED_PAIR [A, B]
feature
a: A
b: B
end
class BINARY_RELATION [A, B]
inherit
MY_SET [ORDERED_PAIR [A, B]]
end
class HOMOGENEOUS_PAIR [A]
inherit
ORDERED_PAIR [A, A]
feature
is_identical: BOOLEAN
-- Are `a' and `b' equal?
end
class ENDORELATION [A]
inherit
BINARY_RELATION [A, A]
MY_SET [HOMOGENEOUS_PAIR [A]]
end
The code above is, obviously, only a sketch. Consider the class
ENDORELATION [A]. It is a kind of BINARY_RELATION [A, A], i.e. a MY_SET
[ORDERED_PAIR [A, A]]. There are several scenarios where ENDORELATION
[A] *should* be seen as a MY_SET [HOMOGENEOUS_PAIR [A]]. For instance,
{HOMOGENEOUS_PAIR [A]}.`is_identical' is a query that would not fit
naturally in ORDERED_PAIR [A, B]. And is not available in ORDERED_PAIR
[A, A], despite the generic parameters of same type. But it is a kind of
query that an ENDORELATION [A] certainly needs to ask to its pairs.
Sure, I can write an {ENDORELATION [A]}.pair_is_identical (p:
ORDERED_PAIR [A, A]): BOOLEAN feature. And, yes, I have done that or
whatever I need to workaround the fact that my ENDORELATION can't be at
the same time a BINARY_RELATION and a set of HOMOGENEOUS_PAIR as is
taxonomically natural.
What if my ENDORELATION [A] object is attached to a MY_SET [ORDERED_PAIR
[A, A]] entity and the latter tries to put an ORDERED_PAIR [A, A]
instead of an HOMOGENEOUS_PAIR [A] into may endorelation? As I've said,
by renaming and selecting, I managed to deal with such a case, easily
converting an ORDERED_PAIR [A, A] into an HOMOGENEOUS_PAIR [A] before
putting it into my endorelation.
In time: the above inherit clause of ENDORELATION compiles, though, as
you clarified, it should not (according to ECMA-367). In my unpretending
opinion, it should.
As to the catcall problem... It is sad. Eiffel is 32 years old. Time to
get rid of catcalls once and for all.
Once more, thanks for your attention.
Rosivaldo.
PS: In 1985 two amazing things were born: the Time DeLorean and the
Eiffel language. I take a chance on saying that 2015 came and went away
without gracing us with some astonishing technological advances seen in
Back to the Future Part II because Eiffel was not healed of catcalls in
the early nineties. ;-)
PS 2: My English is not that good for so detailed texts. Please forgive
any fault of mine.
Em 17/02/2017 15:17, 'Alexander Kogtenkov' via Eiffel Users escreveu:
> It looks like there is an issue if the rule is relaxed. Indeed, in the
> example with SET [STRING] and SET [COMPARABLE] there is some
> intermediate ancestor X that inherits SET [COMPARABLE]. Therefore, it is
> possible to assign current type that conforms to SET [STRING] to a
> variable of type X:
>
> x: X -- X inherits SET [COMPARABLE]
> ...
> x := set_of_strings -- a type of set_of_strings inherits X and SET
> [STRING]
>
> Now it becomes possible to insert values other than strings into x:
>
> x.put (2017)
>
> Then, set_of_strings will have an integer inside it and this is wrong.
> So, there are little chances that the rule can be relaxed. It might be
> possible to do that, but features with covariant arguments could not be
> called in that case.
>
> Regards,
> Alexander Kogtenkov
>
>
> (...)