Nathan, Nathan Bubna wrote:
On Mon, Mar 10, 2008 at 1:12 PM, Christopher SchultzMy list elements are java.lang.Integer objects, so in the eyes of Velocity, there is an ambiguity, here.eek.
Yeah. :(
Velocity happens to pick remove(int) when I'd prefer remove(Object) in my case.but would you prefer that in general? i'm guessing not. i think Velocity is doing the right thing here and suspect you'd agree.
I do agree, and wasn't really suggesting that Velocity should act any differently (in this case). I was just wondering if...
Is there a way to force Velocity to pick a particular version of a method? In Java, you'd just cast the object to a particular class to remove any ambiguity, but that option is not available for Velocity.no, and i can't think of any easy way to do it with adding syntax for casting or making it so the Uberspect does the "generally wrong" thing here. and i think i'd oppose either of those, the first on grounds of barely useful complication and the latter because it would be backwards incompatible and i think not fit the general use-case. i suppose you could hack up a custom Uberspect or Introspector that watches for this special case and use that for your application, but that seems ugly.
Yup, I completely agree. In some respects, this is really a problem with the List API itself because the overloaded remove method has two different semantics. This is quite a special case, really.
Any suggestions?i'd suggesting looking for another way to have your template do as you wish. removeAll(Collection)? a tool? something else entirely?
Instead of $myList.remove($myInt), I did use $myList.removeAll([$myInt]), which satisfied my needs. I was just looking for a possibly more elegant solution.
-chris
signature.asc
Description: OpenPGP digital signature
