Re: findOne signatures refactoring

[Jacques Le Roux]

I had 2 values

changing a method call from ellipsis signature to the other. I introduced 
UtilMisc.toMap for the last argument because I had 2
values and changed for one only, hence ellipsis could not be used. I did that 
in a hurry, not thinking about the argument swap.

Let me try to explain from your example:

delegator.findOne("Entity", true, "field1", value1, "field2", value2);
and tried to change it to:
delegator.findOne("Entity", true, UtilMisc.toMap("field1", value1));

As you can see the 2d line is taken by the compiles has being using the 1st 
signature. So it compiles, but is wrong.
The last cons at http://www.codeproject.com/KB/java/Java5FeaturesII.aspx#pre10 
explains the reason


Jacques



Scott Gray wrote:

<<If you are not careful, you may have trouble with method overloading as the varargs may increase the chance of parameter collision when methods are overloaded.>>

No matter how many times I read what you've written below I can't understand 
what issue you ran into?

You had:
delegator.findOne("Entity", true, "field1", value1);
and you tried to change it to:
delegator.findOne("Entity", true, UtilMisc.toMap("field1", value1));
?

That should still work since findOne(String, boolean, Object...) would still be 
used and it calls UtilMisc.toMap(Object...) which
supports exactly this scenario.  What is the problem?

Regards
Scott

On 27/09/2011, at 8:24 PM, Jacques Le Roux wrote:

Hi,

I suggest to refactor findOne signatures. Or actually only the signature w/out 
ellipsis. When we introduced the signature with
elilpsis the cache argument was inevitably in the middle. We kept the signature 
for the other method. I was caught recently by
changing a method call from ellipsis signature to the other. I introduced 
UtilMisc.toMap for the last argument because I had 2
values and changed for one only, hence ellipsis could not be used. I did that 
in a hurry, not thinking about the argument swap.

So it would be only a matter of swapping the cache argument from last place to 
second in the old signature. IMO it makes sense
to have "consistent" signatures... Maybe findOne is not the only one to 
change...

Opinions?

Jacques

smime.p7s
Description: S/MIME cryptographic signature