Reinier Zwitserloot wrote: > The reason extension methods are inevitable is because of java's rigid > adherence to backwards compatibility. So, if you have to be backwards > compatible, and interfaces like java.util.List will NEVER change (even > WITH versioning, as lists are routinely transferred across modules - > that's Mark Reinhold talking, so consider it canon). Thus, extension > methods. That's, again, Mark Reinhold (though I'm paraphrasing. I > wasn't running around devoxx with a recorder :P) > > Technically it seems like a bit of a lie, practically, I really see no > problem whatsoever. "It's a lie", you say. Really? Is "list.sort();" a > lie? I don't see how it practically will ever be one. It sorts list. I > don't think the detail "sort is a method that has been virtually > looked up via the object that is being pointed at by the reference > variable named 'list'" holds much relevance here. > It's a lie in that it claims that list has a sort() method.
That's a lie. One might wish it was true, but it's not. Nor should every action on a List be a member function of list. > And, of course, it's trivial for the compiler / editor / style > checker / pretty printer / whatever to figure out what's happening and > give you a tool to tell these things apart. I would expect the IDEs to > render such a call the same way as a static method (example: In > eclipse, "sort" would be italicized). > Readability should not rely upon a fancy IDE. I love my IDE, but the text should speak for itself. > Presumably, imports can gain a scope level and be moved to package- > info and module-info in such a way that you can configure a bunch of > static and extension imports ONCE per module, and use them everywhere > else. That's even worse. Then you're left wondering what the heck "sort()" is here and where the heck it came from. Again, an IDE might come to the rescue, but one should not have to rely upon the IDE for this. In the very worst case one should need an entire source file (without an IDE) for things to be clear (as with static imports) -- not the source for an entire module! There's no value in the lie that sort() is a method of List. Some ivory tower folk may think OO means every action is a method of the noun on for which it is the principal verb. That's not realistic or reasonable. A statically typed class should have a single set of methods -- not a hypergraph thereof. If you want that, go with a dynamic language and meta-programming. Other modules inevitably will add more verbs for that noun. They shouldn't lie to everyone and say they're part of the original class. Rather there should be utility classes that clearly and explicitly encapsulate these verbs outside the original class and clearly in the appropriate module. In essence the drive for call site extension methods is just OO purity run amuck! > There's some precedent for this; in eclipse, you can configure > (IDE-wide, so that's clearly kludgey) standard static imports. In > practice, this means you can auto-complete these and if the static > import isn't already in the source file, it's added as you > autocomplete. Especially with such a feature, lists really WILL gain a > sort method. It won't be virtual, but this is mostly irrelevant to me; > whenever I am coding and I want to do something to this list, I want > to type: > > "l", "i", "s", "t", ".", "ctrl+space", and pick sort out of the list. > If I can't, that sucks. Sucks way more than any concerns about magic > going on with extension imports. > Yes. I really, really dislike static imports in /most /cases. I'll use them in preference to having my class "implement" an interface class which defines a set of constants (as this is a royal hack), but that's about it. Local clarity is really important -- source characters are cheap. -- Jess Holle -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=.
