extension methods, etc...

[Jess Holle]

Just listening to the latest podcast...

extension methods [as presented at least] --> yuck!  I agree with Joe, this is only good for muddying the waters.

Same for chaining of void methods, though I'm much more ambivalent on this one.  I'm fine with just doing:

A  a;
{
  ABuilder  builder = new ABuilder();
  builder.setX( x );
  builder.setY( y );
  ...
  a = builder.build();
}

rather than:

A  a = new ABuilder().setX( x ).setY( y ). ... .build();

sure it is more lines of code, but the former makes stack traces and debugging much easier.

Sure you can also do:

A  a = new ABuilder()
  .setX( x )
  .setY( y )
  ...
  .build();

to improve stack traces and debugging but that's no more readable than the first case.

Of course, if you really want chaining you can just design this in by returning 'this'.

--
Jess Holle

[Reinier Zwitserloot]

On the topic of extension methods:

Assuming for a moment that we can all agree that 'list.sort();' is
just plain better than 'Collections.sort(list);', the question
becomes: How do we add it.

This is fraught with such endless problems, that the only even
remotely lightweight way to accomplish this is indeed extension
methods as proposed; the 'client' code, so to speak, must do the
import. Fortunately IDEs can help and e.g. eclipse already has a
feature whereby you can specify classes which are assumed to be
statically imported into everything. This doesn't actually happen, but
the auto-completer assumes they do, and silently adds the import
static if you use it. Useful to toss e.g. java.lang.Math.*; in there.
You could then pull the same stunt for Collections.sort.

Because of that I'm in favour of extension methods. The verdict on
import static is already that you should not use them if there's any
possible chance of confusion. Given that java programmers are already
properly trained in the sparing usage of import static, this seems
like a fine addition.

The question possibly boils down to this: What do you think is better:

sort(list); (where auto-completion is a bit weird, in that 'sort' is
suggested as if it's a local method, eventhough it isn't),

or:

list.sort(); (where auto-completion is less weird, in that 'sort' is
suggested as a method of lists, eventhough it's not).


To me, the latter looks much more sane, though I can certainly see an
argument that neither is a good idea. For those people, just don't use
that kind of static import - in which case neither would work.

[Kevin Wong]

> Assuming for a moment that we can all agree that 'list.sort();' is
> just plain better than 'Collections.sort(list);', the question
> becomes: How do we add it.

Not so fast. I don't think it's a given that it is better. There's a
reason why List doesn't have a sort() method (even though we
desperately want it to), and compiler magic shouldn't make it look
like it has. Why can't code just look like what it actually does.
And isn't this a little petty; I mean we're not even saving a full
line of code here.

Now, if we talking about _actually_ adding a sort() method to a list
of Comparables, that would be another story. Perhaps there is a
solution involving a ComparableList interface, traits, mixins, etc.

I think Java's a damn good general-purpose language. Perhaps we
should focus on substantive improvements and not monkey with things
that aren't broken.

[Jess Holle]

This sort of "extension" just lies to the reader.  It says that sort() is a method of Collection when it is not.

There's no value in saying this other than maybe that some wish it were so.  Since it isn't saying it is so makes just makes things harder to follow.  Sure an IDE can help you understand the incomprehensible, but the clearer plain source text is (without having to always cross-reference to import statements) the better.

I use static imports very sparingly for this reason as well.  In that case, however, at least the author of a single Java source file has chosen to simply reduce the namespacing normally afforded statics of other classes.  This is consistent with import semantics in general.  Still I can count on 1 hand the times I've used static imports.  I don't even use them in JUnit tests.

--
Jess Holle

[Jess Holle]

Kevin Wong wrote:
> I think Java's a damn good general-purpose language. Perhaps we
> should focus on substantive improvements and not monkey with things
> that aren't broken.
>

Agreed.

Throwing in syntactic sugar for every knee-jerk "use case X would look a
bit better (to me) with _____" feature will not improve readability and
not make any real substantive improvement to the language.

Java's pretty darn good. Sure there are plenty of things that could and
should be added/improved, e.g. closures, but it is critical to (1) get
these things right rather than rush them in and (2) introduce only those
things that bring a substantive net improvement -- introducing other
features only leads to conceptual bloat and makes the whole language
harder to learn, read, remember, and, comprehend.

--
Jess Holle

[Reinier Zwitserloot]

On Nov 28, 7:39 am, Kevin Wong <kevin.peter.w...@gmail.com> wrote:
> Not so fast. I don't think it's a given that it is better. There's a
> reason why List doesn't have a sort() method (even though we
> desperately want it to)

and the reason is: It wasn't part of the original List interface, and
due to backward compatibility issues, it can not be added. *BECAUSE*
java is extremely backwards compatible, some way to extend existing
interfaces is extra important.

> , and compiler magic shouldn't make it look
> like it has. Why can't code just look like what it actually does.

You're acting as if there's some enormous difference between the
hypothetical situation that List had a sort method in it (and
AbstractList implemented the same thing that Collections.sort does
now), and the current status quo. There really isn't; it's just that
what we have now makes little sense and looks ugly.

In an OO language, to sort a list, you call the sort method on said
list. Any deviation from this is a code error. I can see an argument
where the cure is worse than the disease (and, in fact, I more or less
agree to this sentiment), but suggesting that Collections.sort(list)
is how it should be - I just don't get that.

> And isn't this a little petty; I mean we're not even saving a full
> line of code here.

This isn't the only place. We're talking about the ability to add
functionality to existing stuff. This is hardly petty.

> Now, if we talking about _actually_ adding a sort() method to a list
> of Comparables, that would be another story. Perhaps there is a
> solution involving a ComparableList interface, traits, mixins, etc.

'traits', 'mixins'? What do you think this is? A low impact syntactic
sugary way of writing mixins!

>
> I think Java's a damn good general-purpose language. Perhaps we
> should focus on substantive improvements and not monkey with things
> that aren't broken.

With that reasoning, generics and annotations suck. And yet they
don't.

[Reinier Zwitserloot]

On Nov 28, 12:04 pm, Jess Holle <je...@ptc.com> wrote:
> There's no value in saying this other than maybe that some wish it were
> so. Since it isn't saying it is so makes just makes things harder to
> follow. Sure an IDE can help you understand the incomprehensible, but
> the clearer plain source text is (without having to always
> cross-reference to import statements) the better.

There is *NO* difference between list.sort() and
Collections.sort(list) in look and functionality. They both sort
lists, and looking at just that one snippet of code, it's obvious
that's what's happening. You seem rather hung up on the distinction on
where the code is actually defined. This is good; it's a very
important concept that a host of languages just plain ignore (Just
about any language that heavily relies on Dynamic MetaProgramming, for
example in java where e.g. date libraries add the 'minutes()' function
to the Number class by doing something like Number.minutes =
function() {} *AT RUNTIME*, making it absolutely impossible for a
compiler, IDE, or even a human being given a sufficiently complex case
to find out where the 'minutes' bit in:

"(5).minutes()" comes from, or if its even valid at that time.

However, in this case, it's perfectly obvious, and a simple mouse-over
or cmd/ctrl+click will take you right to it. (to a compiler/tooling at
least, and as we're talking static imports, it's either A) obvious to
the programmer, or B) programmer is an idiot for abusing the feature.
No matter how often it's said, java does not prevent idiots from
shooting themselves in the foot. That's a myth that doesn't pan out).

I reiterate a sentiment I often miss in these discussions: Java has
strengths, and weaknesses. Play to its strengths. One of java's
strengths is that 95% of all java devvers use an intelligent editor,
which is capable of telling you exactly where a given identifier is
coming from. Given that 95% of all java programmers have that feature,
and the remaining 5% could easily get it, why ignore it? Why try to
throw 'eeegh, unreadable if I'm looking at this with notepad'
arguments up? I don't give a flying you know what if notepad java
programmers will lose track of things if their project grows large.
Managing a large project in a dumb editor is itself just stupidity at
work. If you like that sort of thing, go use python or other DMP
languages. Those are much better at it.

Now, I don't actually want this feature, but not for the simplistic
arguments so far. I don't want it for this much more complicated
issue:

What if a given list actually implements sort() by itself? Do we use
that? But, in that case, where's the canonical sort? If the List
interface had a sort method, then the canonical method name is
java.util.List.sort(), and all is well. With this mixing feature, the -
only- available canonical sort name is just 'sort', which lacks a
namespace, and that's a big problem. I don't have a solution to it. I
would personally say that list.sort() is syntactic sugar and will be
converted (at compile time) to Collections.sort(list).
Collections.sort will be called *EVEN* if the particular instance of
this list actually did have a sort method. At least with requiring a
static import on the code using the library, you make this obvious.
Which is why I'm certainly not going to complain if this code change
does make it into a future version of java. If the mixin definition is
placed anywhere else, unless this issue is hashed out properly, I'm
not happy with it.

None of which has anything to do with supposed unreadability or
confusion. That's what IDEs are for.

[Jess Holle]

Reinier Zwitserloot wrote:

On Nov 28, 12:04 pm, Jess Holle <je...@ptc.com> wrote:
  

There's no value in saying this other than maybe that some wish it were
so.  Since it isn't saying it is so makes just makes things harder to
follow.  Sure an IDE can help you understand the incomprehensible, but
the clearer plain source text is (without having to always
cross-reference to import statements) the better.
    

There is *NO* difference between list.sort() and
Collections.sort(list) in look and functionality. They both sort
lists, and looking at just that one snippet of code, it's obvious
that's what's happening. You seem rather hung up on the distinction on
where the code is actually defined. This is good; it's a very
important concept that a host of languages just plain ignore (Just
about any language that heavily relies on Dynamic MetaProgramming, for
example in java where e.g. date libraries add the 'minutes()' function
to the Number class by doing something like Number.minutes =
function() {} *AT RUNTIME*, making it absolutely impossible for a
compiler, IDE, or even a human being given a sufficiently complex case
to find out where the 'minutes' bit in:
  

Yes, this form of meta-programming is very troublesome in large systems in my opinion.

1. It makes the location of sort() [or the like] hard to determine -- to no real useful purpose in this example except some odd notion of purity of OO syntax.
2. Dynamically adding methods at runtime makes tracking what methods a class or instance has and where they came from rather messy.
   

None of which has anything to do with supposed unreadability or
confusion. That's what IDEs are for.
  

I love my IDE.

That said, I strongly feel that any language which requires an IDE to eliminate confusion or produce readability has failed.  If you can't understand the code from a snippet in an e-mail or a printout, then it's on to the next language for me.

--
Jess Holle

[Jess Holle]

Jess Holle wrote:

There is *NO* difference between list.sort() and
Collections.sort(list) in look and functionality. They both sort
lists, and looking at just that one snippet of code, it's obvious
that's what's happening. You seem rather hung up on the distinction on
where the code is actually defined. This is good; it's a very
important concept that a host of languages just plain ignore (Just
about any language that heavily relies on Dynamic MetaProgramming, for
example in java where e.g. date libraries add the 'minutes()' function
to the Number class by doing something like Number.minutes =
function() {} *AT RUNTIME*, making it absolutely impossible for a
compiler, IDE, or even a human being given a sufficiently complex case
to find out where the 'minutes' bit in:
  

Yes, this form of meta-programming is very troublesome in large systems in my opinion.

1. It makes the location of sort() [or the like] hard to determine -- to no real useful purpose in this example except some odd notion of purity of OO syntax.
2. Dynamically adding methods at runtime makes tracking what methods a class or instance has and where they came from rather messy.
   

P.S. In targeted cases where I find this truly necessary, then AspectJ and various other aspect-oriented tools do the job just fine.  These cases strike me as the exception to the norm and generally are nice tools to solve particular corner cases.  The bulk of the coding is better without this feature lest developers get tempted to get "creative" and add methods in odd places on-the-fly via metaprogramming instead of putting them where they should be statically.  When this becomes sufficiently unworkable, *then* you cry uncle and make targeted use of AspectJ, etc.

--
Jess Holle

[Reinier Zwitserloot]

On Nov 29, 1:03 am, Jess Holle <je...@ptc.com> wrote:

> That said, I strongly feel that any language which requires an IDE to
> eliminate confusion or produce readability has failed. If you can't
> understand the code from a snippet in an e-mail or a printout, then it's
> on to the next language for me.

Are you sure?

I'll go right out on a limb and say this:

Java (just the language, not the JVM or the libraries) has failed
according to that definition. As do most other languages. Thems the
breaks; programming is hard.

I think it's the other way around. Any language which makes further
tooling difficult is not so great. I don't acknowledge that
programming is intrinsically defined to be 'writing characters into a
text buffer, then feeding this raw text buffer into some sort of
processor', with bells and whistles to the process.

Adding features with the full presumption that they make sense only
with extra tooling in place is in fact perfectly fine, and I'd say 95%
of the use case for annotations fall into this domain. I'm cheating a
bit here, in that I just silently jumped from 'tooling for editing
code' to 'tooling for code in general', but IDEs are here to stay, and
they aren't dirty compromises. They are anything but; any language
which must be edited in an unintelligent text editor is a dirty
compromise!

[Kevin Wong]

> and the reason is: It wasn't part of the original List interface, and
> due to backward compatibility issues, it can not be added. *BECAUSE*
> java is extremely backwards compatible, some way to extend existing
> interfaces is extra important.

I might be wrong, but I believe the reason List doesn't have a sort
method is that not all lists are sortable, as not all objects
implement Comparable.

>
> > , and compiler magic shouldn't make it look
> > like it has. Why can't code just look like what it actually does.
>
> You're acting as if there's some enormous difference between the
> hypothetical situation that List had a sort method in it (and
> AbstractList implemented the same thing that Collections.sort does
> now), and the current status quo. There really isn't; it's just that
> what we have now makes little sense and looks ugly.
>
> In an OO language, to sort a list, you call the sort method on said
> list. Any deviation from this is a code error. I can see an argument
> where the cure is worse than the disease (and, in fact, I more or less
> agree to this sentiment), but suggesting that Collections.sort(list)
> is how it should be - I just don't get that.

I think that all depends what we want List to be. If we decide that a
List should always be sortable, then we should go ahead and fix the
problem at the source; backwards compatibility be damned. Using
compiler tricks to kinda sorta add methods to classes after the fact
seems like hackery. Don't get me wrong, I do see an OO problem with
Collections.sort(list), I just don't think this is the solution.

> This isn't the only place. We're talking about the ability to add
> functionality to existing stuff. This is hardly petty.

But you're not adding functionality at all, are you. You're just
deceiving the reader into _thinking_ that functionality has been
added. I don't know that looking like OO and actually being OO are
the same thing.

> > I think Java's a damn good general-purpose language. Perhaps we
> > should focus on substantive improvements and not monkey with things
> > that aren't broken.
>
> With that reasoning, generics and annotations suck. And yet they
> don't.

That's not true, as generics and annotations do indeed entail
substantive improvements.

[Reinier Zwitserloot]

On Nov 29, 6:22 pm, Kevin Wong <kevin.peter.w...@gmail.com> wrote:
>
> I might be wrong, but I believe the reason List doesn't have a sort
> method is that not all lists are sortable, as not all objects
> implement Comparable.
>

You're wrong. If that was the case, list would still have
sort(Comparator), and it doesn't.

>
> I think that all depends what we want List to be. If we decide that a
> List should always be sortable, then we should go ahead and fix the
> problem at the source; backwards compatibility be damned. Using
> compiler tricks to kinda sorta add methods to classes after the fact
> seems like hackery.

Of course it's hackery! That's the point!

Saying 'backwards compatibility be damned' about a java feature is
just plain not realistic. Java will never damn backwards compatibility
willy nilly. Don't forget that this isn't just for sort. There are
gazillions of interfaces out there that are missing a method and
optimally need something added to it. The scope of this is most
definitely -not- just: sorting lists doesn't look pretty.

>
> But you're not adding functionality at all, are you. You're just
> deceiving the reader into _thinking_ that functionality has been
> added. I don't know that looking like OO and actually being OO are
> the same thing.

Of course it's adding functionality. It's an issue of namespacing.
Everyone knows about Collections.sort, sure. But this doesn't scale;
all of a sudden, to do List operations, you need to know about both
List *AND* Collections. That's just inefficient. I'd be much happier
if interfaces can contain static methods*, which would alleviate this
problem as well, though the syntax will still throw you off a little
bit. This is what would happen:

list.(Hit CTRL+SPACE to activate auto complete - see 'sort' in
dropdown - select sort - be puzzled about the need to pass the list
AGAIN - realize it's a static function - replace original list
instance var with List - continue coding).

I sure hope IDEs do that automatically for you, and I have no doubt
they will, which will shorten that process considerably, but it's
still ugly...

and hacks to take away the ugly are not by definition bad.

>
> > > I think Java's a damn good general-purpose language. Perhaps we
> > > should focus on substantive improvements and not monkey with things
> > > that aren't broken.
>
> > With that reasoning, generics and annotations suck. And yet they
> > don't.
>
> That's not true, as generics and annotations do indeed entail
> substantive improvements.

But so is this. I mentioned annotations specifically because
originally, three quarters of the java community though: obscure way
to add keywords like @Override and @IgnoreWarning without running into
the same 'assert' fiasco. Eh.

*) static methods fundamentally do not belong to instances *AND*
fundamentally do not belong with the class hierarchy. The compiler
always binds static methods at compile time and does not use 'virtual'
lookup like it does for instance methods, and thus any appearance of
object-calling is a sham. Therefore, a static method in an interface
couldn't possibly mean 'Any classes implementing this interface must
also implement this static method as a class', and therefore the
compiler error if you try is simply a wake up call that you're being
stupid. The real reason static methods are always written inside a
class, instead of just verbatim, is because they need a namespace. We
need to go Collections.sort, we can't just add 'sort' to the global
namespace, that's not how java works. As Interfaces are just as valid
as a type as classes, adding a defined static method to an interface
makes perfect sense.

Currently, if you try to write a static method in an interface, you
get an error (but, if you add a (non-interface) inner type to an
interface, you don't, so you can conceivably create something like
List.Utils.sort) that static methods in interfaces make no sense.
Compilers telling you you're having a brainfart are a good thing, but
fortunately we don't actually lose this: If someone honestly thinks
they can add a static method to an interface to force implementors to
write implementations for that static interface, they will write this:

public static someMethod();

note the semi-colon at the end. Not legal. Compiler can still shout at
you for not understanding.

[Jess Holle]

Reinier Zwitserloot wrote:

list.(Hit CTRL+SPACE to activate auto complete - see 'sort' in
dropdown - select sort - be puzzled about the need to pass the list
AGAIN - realize it's a static function - replace original list
instance var with List - continue coding).
  

Realistically not everything is a method of your objects.  There are external utilities that operate *on* your objects that are not fundamentally part of your objects.  Besides utilities coming into existing after object classes this can be a very important distinction.

list.sort();

means any/all lists can define their own sorting any way they choose -- caveat emptor.

On the other hand:

Collections.sort( list );

means there is a single Collections utility class that defines a sort algorithm on lists.  Lists don't get to screw this up in any way -- except where Collections delegates to 'list'.

This is very, very important to know when reading the code in many cases.

I think realistically what you want is for the IDE to be smarter when you type "list." followed by Ctrl-Space, i.e. to find static utility methods whose first argument can take a list as well (and then re-write the line appropriately if you select such a utility, of course).  The IDE could certainly do this and you wouldn't have to know anything about List or Collections a priori.  The IDE would, of course, have to have somewhat better/differently indexed database of code than it has right now, but that's quite doable.  [I use the NetBeans classfile module from a custom app to analyze over 150MB of classes and store all method, field, and usage information in a indexed relational database for very speedy static analysis queries from a shared web app -- though I must admit that I currently don't relationalize or index the individual argument types at this point, just overall signatures.]

--
Jess Holle

[Mark Derricutt]

Maybe we need a way to explicitly state that we're using an extended method, this would solve the "must be readable and understandable at a glance" problem.  To reuse a syntax that's been proposed for properties:

  list->sort();

We're calling -a- sort() method on list, and its a method that much be explicitly statically imported.

Maybe the import also needs to be explicit:

import static com.foo.Bar.sort () on java.util.ArrayList;

Or even something entirely new:

extend java.util.ArrayList with com.foo.Bar.sort();

On 11/30/07, Jess Holle <je...@ptc.com> wrote:

list.sort();

[Jess Holle]

Mark Derricutt wrote:

Maybe we need a way to explicitly state that we're using an extended method, this would solve the "must be readable and understandable at a glance" problem.  To reuse a syntax that's been proposed for properties:

  list->sort();

We're calling -a- sort() method on list, and its a method that much be explicitly statically imported.

Maybe the import also needs to be explicit:

import static com.foo.Bar.sort () on java.util.ArrayList;

Or even something entirely new:

extend java.util.ArrayList with com.foo.Bar.sort();

Those are all more palatable proposals than the original.

All that said, I don't see any value here -- this just obfuscates / complicates things for the reader (albeit less so in the proposal above) with no real benefits.

[Kevin Wong]

The more I think about it the more I see the value of something _like_
this. I use a lot of XxxUtils classes, e.g., StringUtils, MapUtils,
ListUtils. Another solution would be to create an formal construct to
hold add-on methods:

public mixin ListUtils : List //means ListUtils adds methods to the
type List
{
void sort() {
Collections.sort(this);
}
}

This way it would be explicit that we're adding methods to a type, and
should be less astonishing to code readers than magically matching
static methods with a first param of the same type.

This is similar to "categories" in Objective-C, except that in that
case dynamic binding makes the static import unnecessary.

[Alan Kent]

A quick observation on extension methods. We developed an internal OO
scripting language with the equivalent of extension methods. You can
define functions that *look* like they are part of a class without
modifying the class. The most common use was "I want an extra method in
class X - I cannot modify X myself, so I will do it as an extension".

The biggest problem we hit with them was:
1. A developer would write an extension function to a class that was
missing what he/she wanted.
2. Other programmers would see that function as useful to and copy it.
3. The method became so popular, it was eventually added to the base class.
4. Old programs then broke due to the collision of the extension
function with the base class method.

My point? I think its very important that the extension function
mechanism deals with the problem of the same method being added to the
base class later.

Personally I don't think this feature adds much to the language. I
would be keeping the language lean in this case. Having used extension
functions, I find them useful in small projects (where its more like
scripting) and a pain in big projects - but this is biased by one
particular implementation of extension functions where they were called
exactly like a normal class method.

Alan

[Jess Holle]

Alan Kent wrote:
> Personally I don't think this feature adds much to the language. I
> would be keeping the language lean in this case. Having used extension
> functions, I find them useful in small projects (where its more like
> scripting) and a pain in big projects
>

I'm struck that this is a case for a number of recent feature proposals
for Java. Lots of things seem cool and nifty when you're working on a
small project -- most especially when you're hacking all the code
yourself for the first time.

When you deal with a large project with many developers and many years
of maintenance, then many of these good ideas turn out to be very, very
bad ones.

Given that it is very hard to prevent developers on a large team from
using such features, they're best not to have at all -- unless the
language spec is going to specify standard required compiler such as
"disableFeatureX" which could then be used in integration builds.

Of course there are lots of language features which are just purely good
ideas for large and small projects, e.g. generics :-)

--
Jess Holle

[Kevin Wong]

I didn't think of that. I guess I was right in the first place when I
thought that this was a bad idea.

[Tom Copeland]

On Wed, 2007-11-28 at 18:03 -0600, Jess Holle wrote:
> Yes, this form of meta-programming is very troublesome in large systems in my opinion.
> It makes the location of sort() [or the like] hard to determine -- to no real useful purpose in this example except some odd notion of purity of OO syntax.
> Dynamically adding methods at runtime makes tracking what methods a class or instance has and where they came from rather messy.

At the same time, adding code at runtime can make a large system into a
small system; Ruby's attr_accessor is a fine example of this. I wonder
how many "large" 250KLOC systems could be transformed into smallish
20KLOC systems...

Yours,

Tom

[Reinier Zwitserloot]

On Nov 29, 11:27 pm, Jess Holle <je...@ptc.com> wrote:
> On the other hand:
>
> Collections.sort( list );
>
> means there is a single Collections utility class that defines a sort
> algorithm on lists. Lists don't get to screw this up in any way --
> except where Collections delegates to 'list'.

That's right. The exact same argument applies to:

List.sort(list);

even if an instance of List wanted to redefine sort, it wouldn't
work, because static methods bind at compile time. I think we're on
the same page.

>
> This is very, very important to know when reading the code in many cases.
>
> I think realistically what you want is for the IDE to be smarter when
> you type "list." followed by Ctrl-Space, i.e. to find static utility
> methods whose first argument can take a list as well (and then re-write
> the line appropriately if you select such a utility, of course).

That would absolutely be the idea. IDEs are probably smart enough to
do this at some point, if/when static methods in interfaces becomes
legal.

The
> IDE could /certainly/ do this and you wouldn't have to know anything

> about List or Collections a priori. The IDE would, of course, have to
> have somewhat better/differently indexed database of code than it has
> right now, but that's quite doable.

And some sort of 'icon' or other indicator in the auto-complete list
would not go amiss, but those are all implementation details. It's
possible and simple, we agree.

[Michael Neale]

The ideal solution (for me): Use scala !

It can do all this with its implicit keyword (converting between types
to add methods as needed, when compiling). Very nice.

Also, in scala, operators are just method names (you can have any char
in a method name).

so a + b

is really a.plus(b) - (instead "+" is the method name of course).

The more I look at scala, the more I realise that its expert design
keeps the language so much simpler, yet allows all these advanced
things just as library implementations (something that Java has failed
at very very badly).