[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Liberty-eiffel] renaming of ARRAY comparison features
From: |
Laurie Moye |
Subject: |
[Liberty-eiffel] renaming of ARRAY comparison features |
Date: |
Tue, 14 Jun 2016 18:30:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 |
I have recently got an old SmallEiffel/SmartEifel program to compile
with Liberty. It runs, but immediately crashes with a segmentation fault.
Investigation shows that this is due to a stack overflow caused by
infinite recursion of ARRAY.is_equal.
ARRAY has always had two comparison features. One compares every item in
the arrays with '='. I shall refer to this as the "safe" one as it is
incapable of causing recursion. The other compares the items in the
arrays with "is_equal". I shall refer to this as the "treacherous" one
as it can lead to recursion.
In SmallEiffel and SmartEiffel, the safe comparison feature was called
"is_equal". This conforms to the description of "is_equal" in both ETL
and ECMA-367.
The treacherous version was called "is_equal_map" in SmallEiffel and
SmartEiffel.
In Liberty Eiffel, the name "is_equal" has been taken and given to the
treacherous version. The safe version has been renamed "fast_is_equal".
This is the reason my program crashed. When all occurrences of
"is_equal" are changed to "fast_is_equal" it runs happily.
Neiher SmallEiffel nor SmartEiffel seem to have ever used is_equal_map.
I have never found a use for it. Libery Eiffel does not seem to use
fast_is_equal.
I cannot see why the names would have been changed. Giving the name
"is_equal" to the treacherous version goes againt what I have always
thought the purpose of is_equal to be; namely a shallow comparison
feature in which any objects contained within the objects being tested
are required to be the same set of objects. I have never seen the point
of the treacherous version, If an array contains complex objects which
one wants to compare with something deeper than '=', it is most likely
that the precise details of the comparison will be depend upon the new
class being defined. An inhereted test itself using is_equal is unlikely
to meet any specific requirement, and is a dangerous thing to have
around. This point is made in the wiki:
http://wiki.liberty-eiffel.org/index.php/Comparison_of_objects
in connection with a TRIANGLE class:
"It is very hard to imagine how a good function for comparison could be
defined automatically. In particular, it is not always enough to call
is_equal again on the attribute".
I assume that there was a very good reason for changing the names, but I
can't find any documentation of it. Is there an explanation of it?
Does the compiler now need to use the treacherous version?
Is giving the name "is_equal" to the treacherous version the right thing
to have done?
Best wishes,
Laurie
- [Liberty-eiffel] renaming of ARRAY comparison features,
Laurie Moye <=