Re: [Clirr-devel] MethodSetCheck: changing argument count

[Simon K. <si...@ec...>]

On Mon, 2004-07-05 at 18:04, Lars K=FChne wrote:
> >And what do we report if the old version of Foo was overriding an
> >inherited method, and the new version is not?
> >
>=20
> I agree the algorithm it's not perfect. Not sure if this is reason=20
> enough to remove it completely, maybe it's not that difficult to improv=
e it?

I see this as requiring AI to do properly. Does the user "perceive"
these methods as being the same method or not?

> I'd suggest leaving it in there, release 0.4 and wait for user feedback.

How do we handle the case where the old version of Foo was overriding an
inherited method, and the new version is not?

Below, (1) is the case where the original method was not overriding an
inherited implementation, and (2) where it was.

Right now, we have this:
(1)
  ERROR: Changed X(a) to X(b,c)
(2)
  ERROR: Changed X(a) to X(b,c)
when (2) really isn't an error, because an inherited implementation is
available.

By removing the "argcount changed" code, we would have this
automatically:
(1)
  ERROR: Removed method X(a)
  INFO:  Added method X(b,c)
(2)
  INFO: Removed method X(a), method now in superclass/interface
  INFO: Added method X(b,c)

With the "argcount changed" code, we *could* implement this:
(1)
  ERROR: Changed X(a) to X(b,c)
(2) [suggested]
  INFO: Changed X(a) to X(b,c). This method no=20
  longer overrides inherited method X(a).


I guess I could live with the last option above. But I still think the
simplest option (no "guessing") is better..

Cheers,

Simon