Reinier Zwitserloot wrote: > On Nov 21, 7:41 pm, Fabrizio Giudici <[email protected]> > wrote: > >> [I like list.lookup(Decimator.class).decimate(4);] >> > > I don't really get the benefit you're seeing from: > > list.lookup(Decimator.class).decimate(4); > > compared to: > > Decimator.decimate(list, 4); > Apart from the fact that the discussion started with a advocating the extensions precisely to avoid this use of static methods, there's a huge difference that I've just explained in the previous post: in your example you have a single Decimator which applies to all the lists; in my example each list can have its own Decimator implementation according to some rules. > > Both examples are: > > 1) Unwieldy (in the sense that, when you see it, you get the distinct > feeling that you want your editor to fold some of the extraneous stuff > away so you can get on with reading your source). > > 2) Explicitly referencing source, which is an advantage of sorts, > though not enough of an improvement over implicit reference to warrant > the eyesore. > > 3) Complicate auto-complete and other 'Uh, how did this API work > again?' help. > > >> With that syntax I can extend the functionality at will >> > > Perhaps you do not understand how extension methods work? The *USE > SITE* is where the extensions are defined, so, if you have a custom > sort algorithm that you prefer, you can write: > > import my.customcode.CoolSorter.sort extends java.util.List; > > instead of importing it from Collections and you'll get your > particular flavour of sorting instead. The choices of either the core > JDK, or the author of java.util.Collections, or the author of > java.util.List, cannot force anything particular on you. In the rare > Reiner, but I'm repeating this for the n-time :-) your example is *static*: once you have compiled that code, it's carved in the stone. My code can dynamically pick an implementation at runtime, searching for a provider. Clearly, the list and sort/decimator examples aren't the proper use case for that, as I don't see the need for such a high dynamicity in a sorter, but I suppose we are using them just as a placeholder for generic use cases. > case you want to mix sort flavours inside the same source file, you'll > have to forego extension methods and go back to > ProviderClass.methodName(object); instead of object.methodName(); ProviderClass is *static*. :-) > - > but as, at this point, the implementation source is clearly no longer > a meaningless detail, this would be a good thing. In your proposed > syntax, it's always there, even in the vast majority of cases where > it's trivial boilerplate junking up your source. > > >> "I prefer good design" >> > > And I prefer music that sounds good. Also, art that looks nice. I like > food that tastes good too. Knock it off. > A design which implies that behaviour is *static* rather *dynamic* is a worse design (especially if this is the consequence of a phobia for a few characters more), and this is an objective consideration from OOP best practices, not a subjective one.
-- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people [email protected] -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=.
