Extension Methods

Kieron.Wilkinson at paretopartners.com Kieron.Wilkinson at paretopartners.com
Wed Dec 16 01:37:27 PST 2009



> From: Mark Reinhold <mr at sun.com>
> Sent: 16 December 2009 05:57
>
>> With regard to extension methods, I think the "declaration-site"
>> extensions are mostly worthless. Interfaces shouldn't be used this
way
>> since they are suppose to define a contract to implement. I dare to
>> say this is an abuse of the interface mechanism. ...
>
> I do have some sympathy with this position. At the same time, however,

> I'm reluctant to see the classic collection classes consigned to the
> limits of the language as it stands today.
>
> As I said in the proposal, I don't see extension methods as a critical

> feature for this release. I'd be content to drop them if they prove
> problematic, and consider this issue again in a future release.

I don't know if the following suggestion has merit, but given your other
comments about considering traits in the future, perhaps it is worth
considering making extension methods strictly private to the collection
classes and/or the java.* package? This way, extension methods become
more of an implementation detail, and if it is later decided to swap
that implementation with something like full trait support (yes please!
:), it is hopefully possible to do so - you at least have no external
client code to worry about.

Using the new "closures" with the collection classes would indeed be
fantastic, and not enabling that in some form would, I think, bring on a
wave of new alternative collection libraries (even I have a one, for
functional/immutable uses, that I might feel worth making public), which
wouldn't be a particularly ideal situation.

My motivation for the suggestion is just that I don't really like the
idea of extension methods as a general "language feature". It might be
better if they could be overridden in implementation classes, but I'm
guessing that would also make it a far more difficult problem to
implement...


Kieron Wilkinson

P.S. Apologies in advance for what follows, it's added by the outgoing
email server.


This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.


More information about the lambda-dev mailing list