You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com> on 2008/07/16 07:42:16 UTC
contrived use of extends to access static members
instead of using
import static org.apache.solr.util.SolrPluginUtils.*;
there is an inner class as follows
/** shorten the class references for utilities */
private static class U extends SolrPluginUtils {
/* :NOOP */
}
in two places DismaxQParser and RequesthandlerBase
--
--Noble Paul
Re: contrived use of extends to access static members
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
patch attached
On Fri, Aug 15, 2008 at 1:32 PM, Noble Paul നോബിള് नोब्ळ्
<no...@gmail.com> wrote:
> On Fri, Aug 15, 2008 at 11:28 AM, Chris Hostetter
> <ho...@fucit.org> wrote:
>>
>> : I truly believe SolrPluginUtils.parseFieldBoosts(foo)) is the straight
>> : foward way to call a static method in SolrPluginUtils, extending the
>>
>> like i said: submit a patch and i'll commit it ... i don't mind changing
>> it to the full class name,
> will do that
>>
>>
>>
>> -Hoss
>>
>>
>
>
>
> --
> --Noble Paul
>
--
--Noble Paul
Re: contrived use of extends to access static members
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
On Fri, Aug 15, 2008 at 11:28 AM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : I truly believe SolrPluginUtils.parseFieldBoosts(foo)) is the straight
> : foward way to call a static method in SolrPluginUtils, extending the
>
> like i said: submit a patch and i'll commit it ... i don't mind changing
> it to the full class name,
will do that
>
>
>
> -Hoss
>
>
--
--Noble Paul
Re: contrived use of extends to access static members
Posted by Chris Hostetter <ho...@fucit.org>.
: I truly believe SolrPluginUtils.parseFieldBoosts(foo)) is the straight
: foward way to call a static method in SolrPluginUtils, extending the
like i said: submit a patch and i'll commit it ... i don't mind changing
it to the full class name, i just dont' wnat to use a static import.
-Hoss
Re: contrived use of extends to access static members
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
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
<ho...@fucit.org> 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
Re: contrived use of extends to access static members
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Re: contrived use of extends to access static members
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
This kind of usage is uncommon anywhere. Maybe ,static import pollutes
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
tells you whether is is static or where it belongs to.
may be we should not do a
import static foo.Foo.*
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).
On Tue, Jul 22, 2008 at 11:46 PM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : instead of using
> :
> : import static org.apache.solr.util.SolrPluginUtils.*;
> :
> : there is an inner class as follows
>
> that was intentional ... i'm not a fan of import static in cases like this
> (Utility classes with *lots* of static methods). it pollutes the
> namespace of the current class and makes it hard for people reading the
> code doing the importing to realize which method calls are static and
> come from another utility class.
>
> When people see U.foo(bar) it should be obvious that's a static method
> comming from some Utility class U ... we've just "aliased" U to
> SolrPluginUtils -- and it's easy to see that using any IDE with
> knowledge of the class hierarchy (or in my case: "grep").
>
>
> -Hoss
>
>
--
--Noble Paul
Re: contrived use of extends to access static members
Posted by Chris Hostetter <ho...@fucit.org>.
: instead of using
:
: import static org.apache.solr.util.SolrPluginUtils.*;
:
: there is an inner class as follows
that was intentional ... i'm not a fan of import static in cases like this
(Utility classes with *lots* of static methods). it pollutes the
namespace of the current class and makes it hard for people reading the
code doing the importing to realize which method calls are static and
come from another utility class.
When people see U.foo(bar) it should be obvious that's a static method
comming from some Utility class U ... we've just "aliased" U to
SolrPluginUtils -- and it's easy to see that using any IDE with
knowledge of the class hierarchy (or in my case: "grep").
-Hoss