lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: contrived use of extends to access static members
Date Wed, 06 Aug 2008 22:40:45 GMT

: 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


Mime
View raw message