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

[<lak...@t-...>]

Simon Kitching wrote:

>On Mon, 2004-07-05 at 18:39, Simon Kitching wrote:
>  
>
>>On Mon, 2004-07-05 at 18:04, Lars Kühne wrote:
>>    
>>
>>>>And what do we report if the old version of Foo was overriding an
>>>>inherited method, and the new version is not?
>>>>
>>>>        
>>>>
>>>I agree the algorithm it's not perfect. Not sure if this is reason 
>>>enough to remove it completely, maybe it's not that difficult to improve 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)
>>
>>    
>>

I see your point, and like I said, the algorithm is not perfect.

>>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 
>>  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..
>>    
>>
>
>  
>

Maybe it would be a bit easier to implement if we'd only apply the 
heuristic if the original method does not override anything? That would 
result in

(1)
  ERROR: Changed X(a) to X(b,c)
(2)
  INFO: Removed method X(a), method now in superclass/interface
  INFO: Added method X(b,c)

I think in the "non-override" case the message is much better than 
"removed, added", and I'd like to keep it if possible with reasonable 
implementation efforts.

>I was browsing through the clirr bugtracker, and found this issue from
>Stephen Colebourne which is about just this problem:
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=967288&group_id=89627&atid=590802
>
>In this case, he definitely wanted to see "added + removed" rather than
>"changed". 
>  
>

Yes. Unfortunately I can't find the request/email that led me to 
implementing the heuristic... :-(

Lars