I truly believe SolrPluginUtils.parseFieldBoosts(foo)) is the straight foward way to call a static method in SolrPluginUtils, extending the class and invoking a static method does not make it obvious . static members belong to the class where it is declared .
On Thu, Aug 7, 2008 at 4:10 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : This kind of usage is uncommon anywhere. Maybe ,static import pollutes > > I don't know about "anywhere" ... if nothing else you can see it right > here in Solr :) > > It's essentially the same thing as "import aliasing" or "type aliasing" as > has been proposed many times by many people ... and according to at > least one person from Sun i rememeber talking to, was suppose to be in > java 1.6, but aparently he lied. > > http://www.oreillynet.com/onjava/blog/2003/06/new_static_imports_friend_of_f.html > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4478140 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4194542 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4983159 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4214789 > etc... > > : the namesapce, but users are more used to this (because the language > : recommends this). The reason for introducing static import was to > : avoid this kind of clever tricks. If you are using any modern IDE , it > > The primary reason static import was added (per the 1.5 docs) was as an > alternative to the "Constant Interface Antipattern" in which a public > class implements (or extends) something that should not be part of it's > API, exposing implementation details that should remain hidden > > DismaxQParser and RequestHandlerBase do not implement or extend anything > in a way that pollutes their API. The private static "U" subclasses exist > or a clear purpose, and ar not exposed as part of any API or contract. In > the absence of "import aliasing" it provides a clear, short, prefix for > static methods used in the outerclass, and it's clear to anyone reading > the code that those method calls are *not* local, and come from somewhere > else. > > : avoid this kind of clever tricks. If you are using any modern IDE , it > : tells you whether is is static or where it belongs to. > > We should not make the code ambiguious just because modern IDEs can > provide tools to help people disabiguiate. Particularly in an OpenSource > project where we want to make sure people can easily read the code > regardless of what editor/tools they use ... not to mention things like > reading patches and browsing the SVN repository via HTTP. > > : we can do > : import static foo.Foo.a; > : import static foo.Foo.b; > : > : we must import only those methods we wish to use (to minimize pollution). > > If you really want to minimize the pollution, don't use a static import -- > the way things are now, there is *no* pollution of the method space in > the outer class, the methods are explicitly called on a utility class. > > If there's a concensus that method calls like "U.parseFieldBoosts(foo))" > are confusing then i'm perfectly happy to replace them with > "SolrPluginUtils.parseFieldBoosts(foo))" but using a static import so they > are just "parseFieldBoosts(foo))" certainly isn't going to make the code > less confusing. > > > -Hoss > > -- --Noble Paul
