tag:blogger.com,1999:blog-741750605858169835.post1321006415314160496..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java 7 - Extension methodsStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger33125tag:blogger.com,1999:blog-741750605858169835.post-68663132530363767772016-11-21T11:11:57.959+00:002016-11-21T11:11:57.959+00:00I can't find one I'm afraid.I can't find one I'm afraid.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-4090271099804058092016-11-20T01:31:01.238+00:002016-11-20T01:31:01.238+00:00Link for Peter Ahe article is gone. Can You provid...Link for Peter Ahe article is gone. Can You provide valid URL ?Krunoslav Magazinnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-75053205911559736022007-12-07T23:29:25.000+00:002007-12-07T23:29:25.000+00:00Oh god no. Please no. There is NOTHING wrong wit...Oh god no. Please no. There is NOTHING wrong with sort(list). Java is turning into C++! I LIKE it when I can look at a line of code, and tell EXACTLY what's going on.Juan C Nunohttp://juancnuno.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-12916278799071877392007-12-06T00:15:50.000+00:002007-12-06T00:15:50.000+00:00I posted the following on Peter Ahe Blog, it refer...I posted the following on Peter Ahe Blog, it references this Blog - hence the cross posting:<br /><br />Re. use-site extensions, Josh Bloch is of course right in saying that the trait/mixin/declaration-site aren't as flexible. But I am not totally convinced about the extension mechanism as proposed - maybe I need to know more about it. My particular concerns are:<br /><br />1. They look like they do dynamic dispatch, but they don't.<br />2. They have a limited use case - statically imported static methods<br /><br />Perhaps -> could be used and that this notation is for the first argument of *any* method regardless of how its name is made available and this first argument *includes* the hidden this of instance methods. Therefore you could write:<br /><br />list -> filter( test1 ) -> filter( test2 ); // static void filter(List, Predicate) is statically imported<br /><br />list1 -> addAll( list 2 ) -> addAll( list3 ); // addAll(List) is an instance method in List<br /><br />The above notation is similar to the builder notation, also proposed for Java 7 (new X().setProp1().setProp2() where the props return void) and is meant to combine the two proposals. The same as the builder proposal; the value of the second statement above is list1.addAll( list3 ). Different than the builder proposal; the intermediate values, e.g. list1.addAll( list2 ), are always discarded.<br /><br />Stephen Colebourne has suggested something similar but proposed .do. instead of -> and didn't include the original argument getting passed to all the methods, i.e in the second example above list1 is given to both addAlls in this proposal were as in Stephen's the second addAll receives the value from the first.Howard Lovatthttp://pec.dev.java.net/nonav/compile/index.htmlnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-84122950517521080932007-12-05T23:42:03.000+00:002007-12-05T23:42:03.000+00:00I have right now here a use case where I'd lik...I have right now here a use case where I'd like to have transparent client side extension methods, so I could do some kind of duck typing (by simply switching a single generic type declaration); I have to apply program transformations for achieving this at the moment.<br /><br />Ultimately what I want would be a union type and transparent client side extension methods so I could write sth like:<br /><br />void find(List|Sortable sortMe){ ...<br /> sortMe.sort();<br />...}<br /><br />instead of doing everywhere<br /><br />void find(Object sortMe){ ...<br /> if(sortMe instanceof List){<br /> Collections.sort(sortMe);<br /> }else if(sortMe instanceof Sortable){<br /> ((Sortable)sortMe).sort();<br /> }else throw...<br />...}<br /><br />that wouldn't work with the .do. syntax :-(<br /><br />so should we also discuss union types?Axel Großnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-81164373634932172262007-12-05T13:56:15.000+00:002007-12-05T13:56:15.000+00:00I don't see the point in this entire exercise....I don't see the point in this entire exercise. It misdirects the user from where the sort actually resides and introduces more syntax for developers to understand.<br /><br />So what that not everything you might wish to do on a list is a method of list. That's real life. Inventing ways to make believe everything is just makes it harder to understand the reality.Jess Hollenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-24590784302368699612007-12-05T06:59:22.000+00:002007-12-05T06:59:22.000+00:00Peter Ahe has suggested extending the interfaces i...Peter Ahe has suggested extending the interfaces instead of ad hoc extensions (http://digital-sushi.org/entry/declaration-site-extension-methods). My preferred alternative is to turn interfaces into traits, e.g.:<br /><br />interface X { int foo() { return 1; } }<br /><br />interface Y { int foo() { return 2; } }<br /><br />class XY implements X, Y {<br />public int foo() { // must write a foo to resolve ambiguity<br />return X.foo(); // diambiguate<br />}<br />}Howard Lovatthttp://pec.dev.java.net/nonav/compile/index.htmlnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-73972824446030931292007-12-01T19:35:48.000+00:002007-12-01T19:35:48.000+00:00I would like to have extension possibility for any...I would like to have extension possibility for any existing static function like:<br /><br />public class Foo{<br /> public static int foo(Type x,int y){...}<br />}<br /><br />And then I should decide if I want to use it as extension (like import static):<br /><br /><br />import foo.Type;<br />extension Foo.foo; // first parameter will be extended<br /><br />or maybe:<br />extension Foo.foo(extend Type,int); // one choose witch parameter to extend<br /><br />or readable: <br />extend Type with Foo.foo;<br /><br />than I can use :<br />Type type = new Type();<br />y = type.foo(1);<br /><br />Pros:<br />- you can decide what you can use as extension, and how (2nd approach)<br />- extension is explicit<br />- no changes in existing code<br />- you don't need "do", or "->" any more<br />- you can use "extend MyDsl.*;" and provide full dsl for your code! (only in first approach)<br />- can be used in automatic cleanups :)Krzysztof Kowalczyknoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-66078383514830894852007-12-01T01:18:39.000+00:002007-12-01T01:18:39.000+00:00Thanks for the comments - Ben's exmaple is par...Thanks for the comments - Ben's exmaple is particularly good<br /><br />transform(filter(filter(list, Somthing.class), aPredicate), aTransformation)<br /><br />vs.<br /><br />list.filter(Something.class).filter(aPredicate).transform(aTransformation)<br /><br />However, I want to re-iterate, that I am proposing:<br /><br />list.do.filter(Something.class).do.filter(aPredicate).do.transform(aTransformation)<br /><br />because it makes it clear that the extension method is not actually on the class, but is statically imported.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-82906114097153874812007-11-30T03:54:27.000+00:002007-11-30T03:54:27.000+00:00yury:
if "ten" is a method, you will do...yury:<br /><br />if "ten" is a method, you will do it for any integer? Of course not, but with Extension methods, your example (or something nearly of it) become possible:<br /><br />Integer ten = 10;<br />Date later = ten.minutes().from().now();<br /><br />I even implemented something like that using a fluent interface:<br /><br />Date later = $(10).minutes().from().now();<br /><br />Moreover, readability is not an IDE issue but it is a code issue and is not on the other side of OO programming rules and techniques, but provided by them. Code is not more readable because of extension method such as code is not more readable because of "if" (which abuse could leads to high cyclomatic complexity), "switch" (fall through) and a lot of other language features. Any feature could be used in a wrong way, and could be used in a right way.<br /><br />Kind RegardsMarcos Silva Pereirahttp://marcospereira.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-23008258594795172202007-11-29T09:13:02.000+00:002007-11-29T09:13:02.000+00:00To Marcos: With modern IDEs readability is a very ...To Marcos: With modern IDEs readability is a very personal issue. I have not had any problems with that since I started with Java 8 years ago. It took some time to accept the philosophy of the language and OO programming rules and techniques. And this is much more important then readability. Especially those examples I see here are not convincing. I can also say that the code with extension methods is not readable enough. Perhaps I prefer something like:<br /><br />Date later = ten(minutes) from now <br /><br />So what? Which example is more readable? Why yours is better then mine? And do not tell me about implementation. One can always invent "extend-anything-in-java" feature. I am quit sure I have seen examples...yurynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-61547617562646849532007-11-29T05:19:04.000+00:002007-11-29T05:19:04.000+00:00Extension methods are useful in a lot of cases to ...Extension methods are useful in a lot of cases to add more readability. It is a so much necessary feature to adopt other features - as closures - smoothly. As someone says before here, because of compatibility, none will change List interface.<br /><br />Think about write code like this:<br />Integer ten = 10;<br />Date later = now.add(ten.minutes());<br /><br />This is a huge improve readability (and you could do it for any library), so, don't be afraid of extension methods.Marcos Silva Pereirahttp://marcospereira.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39018160005611132532007-11-28T21:44:36.000+00:002007-11-28T21:44:36.000+00:00Adding marginally useful features that appeal to a...Adding marginally useful features that appeal to a small number of "language geek" developers vs. fixing fundamental Java problems that impact most users/customers is a clear sign that Java is getting ready to jump the shark. Maybe it already has.I. M. A. Cook IInoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-4451003974279115692007-11-28T19:16:06.000+00:002007-11-28T19:16:06.000+00:00To Ben Lings: list.filter(Something.class).filter(...To Ben Lings: list.filter(Something.class).filter(aPredicate).transform(aTransformation) also makes you belive that List interface implements/has the "filter" method. So one may enjoy in this specific context. Then this happy person moves to another project and oops this method is not there or perhaps does something else as in context of the projext someone "extended" it like he wanted.<br /><br />I can understand/accept those extension methods but I think it is matter of design/programming culture. From my point of view it is a hack in OO design/programming.yurynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-58933262076691981592007-11-28T12:47:10.000+00:002007-11-28T12:47:10.000+00:00The advantage of extension methods isn't about...The advantage of extension methods isn't about list.sort() vs sort(list), it's about<br /><br />transform(filter(filter(list, Somthing.class), aPredicate), aTransformation)<br /><br />vs.<br /><br />list.filter(Something.class).filter(aPredicate).transform(aTransformation)<br /><br />[ Using google collections Iterables.* methods ]<br /><br />The first takes several seconds of looking at it to work out which methods and which arguments go together. The second makes it much clearer.Ben Lingsnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-50216587808831370912007-11-28T10:28:00.000+00:002007-11-28T10:28:00.000+00:00Why you always reject discussing design issues and...Why you always reject discussing design issues and propose workarounds to fix flows in architecture? And those workaround typically lead to even worse flows. What happend with OO design and programming? What about maintenance cost of those extended methods? What if you have library A which introduced a "sort" extension and you have library B which relies on its own "sort" extension? How would you manage that?yurynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-81298300293929930802007-11-28T05:31:02.000+00:002007-11-28T05:31:02.000+00:00Extension methods are great.
Instead of allowing o...Extension methods are great.<br />Instead of allowing only set of methods(which are marked with annotation), I believe every method should be extenddable.Kishorehttp://www.gyanlabs.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-38269787912335445652007-11-28T02:56:54.000+00:002007-11-28T02:56:54.000+00:00Stephan,
Cool link.Yes i agree with your DSL orie...Stephan,<br /><br />Cool link.Yes i agree with your DSL oriented proposal and hope it may get implemented .<br /><br />Thanks<br />Prashantprashanthttp://prashantjalasutram.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-54239992481816617502007-11-27T23:35:34.000+00:002007-11-27T23:35:34.000+00:00I agree with vhi, you either make it look like a n...I agree with vhi, you either make it look like a normal method or there just isn't any advantage IMHO.Quintessenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-14797093364032396732007-11-27T23:04:20.000+00:002007-11-27T23:04:20.000+00:00First of all, I think using sort as an example for...First of all, I think using sort as an example for an extension method is misleading... Furthermore, if I have to do list.do.sort(), then it does not bring any benefit to me compared to sort(list). I think the major benefit of an extension method is transparency, which means that the user does not have to know that it is an extension method. If we remove the transparency, then I fail to see any benefit of having extension methods at all. I really suggest you take a look at how it is done in C#.vhinoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-54038904492308944152007-11-27T19:52:01.000+00:002007-11-27T19:52:01.000+00:00Well I guess then I really just don't get it, ...Well I guess then I really just don't get it, sorry. If I want a list that sorts.<br /><br />ListWithSort list = new ListWithSort();<br />list.sort();<br /><br />The implementation of ListWithSort is not significantly more code then your proposal for extensions and it's OO and it's very clear where the code comes from. <br /><br />*shrug* sorry.aberranthttp://aberrantcode.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31091147078487583352007-11-27T18:43:48.000+00:002007-11-27T18:43:48.000+00:00I am not convinced this is the appropriate use of ...I am not convinced this is the appropriate use of annotations in this context. Annotations are "meta-data", extra information and "extension" methods are just static methods that the compiler magically makes them look like methods on the class.<br /><br />Honestly, I don't think extension methods are a "good thing". It destroys readability IMO and by design it masks that it is a static method in another class.<br /><br />Instead of just adding every new language feature from C# 3.0 we must evaluate it's usefulness.Abraham Tehraninoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20586324809561462692007-11-27T17:48:05.000+00:002007-11-27T17:48:05.000+00:00@Aberrant, This is mainly about allowing developer...@Aberrant, This is mainly about allowing developers to 'add' methods to interfaces/classes written by others. For example, the List interface is written by Sun, and can't be changed by the average developer (in fact it can't be changed by anyone due to backwards compatibility).<br /><br />If you want to sort a list, you currently have to use a static method on collections - Collections.sort(List). This change allows you to write this in a more OO style - list.do.sort();<br /><br />Extension methods as described here do not affect all instances of the class, just those in a single source file where the import occurs.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-32503199575425922852007-11-27T17:44:13.000+00:002007-11-27T17:44:13.000+00:00It would be better if JVM (and javac) allowed non-...It would be better if JVM (and javac) allowed non-abstract interface methods.<br /><br />Interface fields will not have fields, so there are no big problems with multiple inheritance.Stepan Koltsovnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-84635352587004884542007-11-27T16:40:33.000+00:002007-11-27T16:40:33.000+00:00What is the scope of this change? Is it adding a m...What is the scope of this change? Is it adding a method to one particular instance of a class, or does it effect all instances of the class created after the extension method has been added? If it's global I can't see how one would manage multiple objects or even multiple threads all competing to inject their own version of the sort method. If it's not global I don't see why it's necessary on any interface or non-final class because you can inherit and implement anything you want. Any final class is final because the author has decided to not let you extend it. So extension methods do not make since there either. What am I missing? What does this make possible that was not possible before?aberranthttp://aberrantcode.blogspot.com/noreply@blogger.com