[pylucene-dev] Bug/JCC: NumberTools.longToString

[Andi Vajda]

On Thu, 15 Nov 2007, Pete wrote:

> This just bit me again.  This code, which worked in PyLucene-gcj, throws an
> exception in lucene-jcc:
>
> DateTools.timeToString(int(value.strftime('%s')),
>                                       DateTools.Resolution.SECOND)
>
> timeToString is expecting a long (kindly ignore the off by 1000x bug).
>
> This at least needs to be in the README.

Agreed. If you send me a patch to the README, I'll apply it.

>>>    - it makes it ambiguous: if there were two java methods called
>>>      longToString(), one taking a long and one taking an int, making the
>>> long one accept int would cause the wrong method to be called if long is
>>> checked before int.
>
> What about when there's no such overloading? ie, when there's a single method
> taking a long, can JCC cast the ints to longs in that case?

Yes, that's part of the complications. parseArgs() would have to be told 
about the existence of overloads, some of which could be inherited, of 
course...

> Again, I'll deal if necessary, but I suspect this going to bite others as
> well.  Debugging would be easier if lucene.InvalidArgsError contained more
> info about which arg was invalid...

Good point, some of that information is readily available. I should forward 
it to the error.

Andi..