[Grace-core] Built-in egality

Michael Homer mwh at ecs.vuw.ac.nz
Fri Dec 13 19:31:09 PST 2013


On Fri, Dec 13, 2013 at 6:09 PM, Andrew P Black <black at cs.pdx.edu> wrote:
> What should Grace's built-in egality method do when asked to compare two objects of different classes?
>
> The current implementation seems to try to examine the fields in the other object, which fails if they are confidential (e.g., if they are defs).  Even if this worked, it would be wrong, because the two classes might use the fields in quite different ways.  The motivating example is range.from()to() and range.from()downTo(), which obviously do different things with the fields start and stop.
This didn't get updated with the change of default visibility. I have
fixed that now (c3443d0).

It does also look at methods. Methods are regarded as egal when they
come from the same point in the source and have the same closure
environment. Baker's version envisages looking at the source code, but
I don't think that's practical when you're not writing Lisp.
> The == method has to exist, because it's not until the method starts execution that it can look at the argument and notice that it's a different class.  The right answer would seem to be "return false"; the programmer can always override the inherited method with a custom method that does something different in this case.
The story (at least initially) was that you couldn't override it at
all. I do think it will be necessary in practice to allow it.

As I've said before though, I don't think egal is overly useful in
practice - it will be true extremely rarely, and virtually only for
pure record objects. As soon as you have methods it's very likely to
fail. Almost always it will be the same as pointer equality. It might
be a sensible default if the cases where it works are common, but
explaining exactly when it will actually be true is going to be pretty
tricky.
-Michael



More information about the Grace-core mailing list