optimize smallest()/largest() (and min()/max()?) for Integer, Float

[gavinking]

Currently smallest() and largest() always box their arguments. I think we should optimize them for Integer and Float arguments, adding native impls with long and float parameters.

A similar optimization is possible for min() and max(), I guess.

[quintesse]

PS: I have always thought we should have a generic mechanism for this, something where, in a declaration, you can mark one of its type parameters as being optimizable. The compiler would then generate extra native implementations. That way this optimization becomes available for everyone and everything.

Btw: the problem is that you can't annotate type parameters, so the other solution would be to annotate the declaration itself and then just select the first type parameter.

[gavinking]

@quintesse That sounds like I good idea but I don't understand why you would need to explicitly mark anything. Just do it: generate the optimizations for any of String, Integer, and Float that are assignable to the constraint.

[quintesse]

@gavinking sure, but that would mean quite an explosion of extra methods, is that maybe something to worry about?

[gavinking]

Perhaps. But generic methods are not all that common.

[quintesse]

True. And this would be something that is only reflected in the implementation of the class, right? Meaning that the public interface as visible from let's say Java would still just show a single generic method but the implementing class would have several extra methods. So something like this would not use the optimization:

void Boolean testOne(Comparable<Integer> cmp) => cmp.largerThan(1);

but this would:

void Boolean testOne(Integer cmp) => cmp.largerThan(1);

am I right?

[gavinking]

It would appear as an overloaded method to Java clients.

On Mon, Apr 13, 2015 at 2:01 PM, Tako Schotanus notifications@github.com wrote:

True. And this would be something that is only reflected in the implementation of the class, right? Meaning that the public interface as visible from let's say Java would still just show a single generic method but the implementing class would have several extra methods. So something like this would not use the optimization:

void Boolean testOne(Comparable cmp) => cmp.compare(1);

but this would:

void Boolean testOne(Integer cmp) => cmp.compare(1);

am I right?

— Reply to this email directly or view it on GitHub https://github.com/ceylon/ceylon-compiler/issues/2125#issuecomment-92327237 .

Gavin King gavin@ceylon-lang.org http://profiles.google.com/gavin.king http://ceylon-lang.org http://hibernate.org http://seamframework.org

[quintesse]

Yes, but what I mean is overloaded only in the implementation class , not in the interface (which would mean everybody would have to implement those methods even if in your class you only use it with Identifiable types)

[gavinking]

I think it's perfectly fine if we don't do this for interface methods for now. Do it only for non-formal non-default methods of classes.

[quintesse]

Ok, still, I hope that at some time we'll get super-optimized versions of thing like get() in List ;)

[gavinking]

Well, sure, but that's much trickier.

[jvasileff]

only for non-formal non-default methods of classes

This would cause binary compatibility to break for methods when they are made default (after previously being non-default). Perhaps it should be limited to non-shared methods for now?