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

[Pete]

On Thursday November 15 2007 7:49:52 pm Andi Vajda wrote:
> Yes, that's the intent.

Plain ints were accepted here by PyLucene-gcj.

> I could make the argument parsing more leniant but this comes with two
> problems:
>
>    - 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.
>      Sure, I could, in some cases, determine the right order for checking
>      overloads (check int before long since long is wider) but this gets
>      pretty complicated.

I see this mostly as an artifact of Python's int/long distinction, which is 
kinda strange to begin with.  That's why they're getting unified: 
http://www.python.org/dev/peps/pep-0237/ 

Out of curiosity, could Java code call longToString() with an int?  From what 
little I remember of my C++ days, I thought this sort of widening-cast was 
handled for you...

>    - it makes things slower by trying out more things than necessary

The joy of dynamic languages.  From the Python programmer's perspective, the 
only difference b/w int & long is when using isinstance() and the later has 
an L on the end when repr()'d.  This type of casting is really un-Pythonic; I 
guess we'll have to get used to a little Java in our lives if it's a pain to 
fix.

> If you want to call longToString(36), use longToString(36L) and all is
> good.

Well, I'm calling it with a variable, and I can wrap it in long().

-- 
Peter Fein   ||   773-575-0694   ||   pfein at pobox.com
http://www.pobox.com/~pfein/   ||   PGP: 0xCCF6AE6B
irc: pfein at freenode.net   ||   jabber: peter.fein at gmail.com