Reinier Zwitserloot wrote: > inline responses... > > On Nov 20, 5:48 pm, Jess Holle <je...@ptc.com> wrote: > >> It's a lie in that it claims that list has a sort() method. >> > There is no such claim. dot instead gains an extra possible meaning > (pass ref to extension method). > That's just ambiguous and confusing rather than a lie then. >> Readability should not rely upon a fancy IDE. I love my IDE, but the >> text should speak for itself. >> > Why? No, seriously, why? It's almost 2010. Perhaps the dumb terminal > model should no longer be held as sacrosanct. The code isn't utter > gobbledygook in a dumb terminal - just includes slightly more > abstraction. I don't see a fire here. > When dealing with large number of modules, some of them large and needing to simply review and understand code having to toss entire modules around or load them up from source control is a real issue. >> That's even worse. Then you're left wondering what the heck "sort()" is >> here and where the heck it came from. >> > Just like x.foo() is a mystery if you don't know the type of x / don't > know what x's type is? Code without context is meaningless. Extension > methods don't change the equation. > The polymorphism is well established and understood here. Extension points add another unfettered dimension here. > Again, an IDE might come to the > >> 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. >> > You ignored my practical reason for this: auto-complete. > Auto-complete could simply put a separator in the drop down and suggest static methods taking the given type as their first argument (excluding Object, of course). Done. If this is a big issue one could have an annotation hinting to IDE's that the method be associated with completion against some types. >> [sky will fall down, all hope is lost, go use dynamic language grandstanding >> omitted] >> > There's no arguing with doomsayers. > >> 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. >> > Static import beats new keywords. > Yes, it's not the syntax that's the issue here -- it's what the syntax *does* that's the issue. It leads to a lot of developer confusion when onne has what appear to be method calls against "this" throughout the code that are nothing of the sort, for instance.
-- 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=.
