[E-Lang] Coming Attractions: Java Overload Resolution

[alphabeta@beta2.freedom.net]

MarkM writes:
> In any case, E <= 0.8.9s has not satisfied the above spec.  When there are 
> multiple Java overloads for the same arity, E <= 0.8.9s would make an 
> arbitrary one available by the simple name.  This was a known bug but a bad 
> one.  A program could seem to work fine one day and then fail the next 
> because it got "lucky" on the arbitrary choice of a Java overload.  It was 
> fatally surprising.

Yes, I got bit by this recently when I upgraded to E 0.8.9 from an
earlier one.  I had some math code assuming that the two-argument
BigInteger constructor was "public BigInteger(int numBits, Random rndSrc)"
This produces a random number of the specified number of bits.  However
after my upgrade it no longer worked because the two-argument constructor
was now "public BigInteger(String val, int radix)".

I figured out the "E call" stuff eventually, but it was hard because it
is quite picky about the formatting of the string that specifies which
initializer you want.  The right answer is:

    E call( integer maker, "new(int, Random)", [bits, rng] )

but you have to have exactly zero spaces after "new" and the parens,
and exactly one space after the comma, for it to work.

> Rather than fixing this bug, starting with E 0.8.9t, E will now correctly 
> implements a much less irritating but still unsurprising spec.  (Thanks to 
> MarcS for help figuring out the new spec.) The new spec is that if the 
> argument list is compatible with exactly one of the overloaded parameter 
> lists, then that method is executed.  Otherwise an exception is thrown.

Wow, so it will check the Java types of the arguments at run time?  That
sounds pretty fancy.

> Does this new rule seem strictly superior and unproblematic to everyone?  

Sounds great to me.

Hal

________________________________________________________________________
Total Internet Privacy -- get your Freedom Nym at http://www.freedom.net