User Tools
eiffel:faq:equality
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
eiffel:faq:equality [2019/08/21 16:44] jonathan |
eiffel:faq:equality [2019/08/21 16:45] (current) jonathan |
||
|---|---|---|---|
| Line 8: | Line 8: | ||
| The first implies the second. In the second, the definition of when objects are “equal” is given by the `is_equal‘ function, in its version for the common type. | The first implies the second. In the second, the definition of when objects are “equal” is given by the `is_equal‘ function, in its version for the common type. | ||
| + | |||
| + | "~" can be seen as an alias to `is_equal' but it is more complicated than that. Per the ECMA spec it is more equivalent to "a.same_type (b) and then a.is_equal (b)". This ensures that no catcalls occur at runtime. | ||
| Previously object equality would have to be written in one of the two forms | Previously object equality would have to be written in one of the two forms | ||
| - | a.is_equal (b) | + | a.is_equal (b) |
| | | ||
| - | equal (a, b) | + | equal (a, b) |
| but they raise the risk of a run-time “catcall” (non-matching types, here harmless in principle but potentially causing a run-time interrupt anyway). The idiom using ~ is always safe, hence preferred. | but they raise the risk of a run-time “catcall” (non-matching types, here harmless in principle but potentially causing a run-time interrupt anyway). The idiom using ~ is always safe, hence preferred. | ||
eiffel/faq/equality.1566405840.txt.gz · Last modified: 2019/08/21 16:44 by jonathan
Page Tools
