Bug 176611

Comment 1 Olivier Thomann 2007-03-07 10:22:37 EST

Maybe isEqualTo(..) should also considered the inferredReturnType information. This would make the two method bindings different.

Comment 2 Markus Keller 2007-03-07 10:38:18 EST

> Maybe isEqualTo(..) should also considered the inferredReturnType information.

That would mean their keys would have to become different, too. IMO, this inference bit should not be part of the binding, since it only makes sense in the calling context (like Expression#resolveBoxing()).

Comment 3 Olivier Thomann 2007-03-07 10:46:28 EST

In this case we store the information in the compiler's binding, so I would say we should also expose it on the DOM/AST binding.
Don't expect the two bindings to be identical since they are not called the same way. If the problem is that isEqualTo(..) or the key are the same for these two bindings, then let's use this information in the key and the isEqualTo(..) call and they won't be the same anymore.
Philippe,

I would expose this information on the binding side inside of the ast node side. Discussing with Kent, he also agrees that the two compiler's bindings should not be identical in this case.

Comment 4 Markus Keller 2007-03-07 11:15:52 EST

IMO, the context should not separate bindings that are otherwise identical. This is also not the case in other scenarios, e.g.

    // bindings for boxing(..) are identical (good):
    void boxing(Integer arg) {
    	boxing(1);
    	boxing(new Integer(1));
    }
    
    
    // bindings for sort(..) are identical (good):
    void sort(ArrayList<String> list) {
    	Collections.sort(list);
    	Collections.<String>sort(list);
    }
    
Another failure case:

    // bindings for get(..) should be identical but are not:
    <T, S> void get(T t, S s) {
    	Object o= new Object();
    	get(o, null);
    	get(null, o);
    }

Comment 5 Philipe Mulet 2007-03-07 11:20:29 EST

I agree these bindings should be identical in the DOM AST... tricky to achieve though since we construct the binding as a substitution gradually, and wouldn't notice it is the same as previous until finished.

Need to change inference process quite deep (or redo caching in the end).

Also need to check all data set on 'identical' bindings, some of these flags would need to be rather on the messageSend (e.g. #inferredReturnType)

Comment 6 Eclipse Genie 2020-04-22 15:41:04 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.