« Return to Thread: Prettiness of Java statics classes: dropping the "make"

Re: Prettiness of Java statics classes: dropping the "make"

by Kevin Reid-2 :: Rate this Message:

Reply to Author | View in Thread

On May 11, 2008, at 11:52, Mark Miller wrote:

> On Sun, May 11, 2008 at 7:53 AM, Kevin Reid <kpreid@...> wrote:
>> On May 11, 2008, at 9:14, David-Sarah Hopwood wrote:
>>> Kevin Reid wrote:
>>>> Java libraries often have classes which are used solely for their
>>>> static fields and methods, not instantiated.
>>>> ...
>>
>>>> As these are basically classes being used as singleton objects, I
>>>> propose that there be a safej option which makes these classes'
>>>> import fqns more fitting:
>>>> [...]
>>>> What do you think of this idea?
>
> I think this idea is workable. I hadn't previously considered placing
> such a switch in the safej file.

> The important constraint on employing this switch is that the class  
> be non-instantiatiable, so a safej file turning on this switch much  
> not also enable any constructors or instance members.

I don't see why this is necessary. The worst result is poor naming,  
which we can't defend against anyway, and so shouldn't pretend to.

> I would also prefer to constrain such classes to be final.

It seems to me that a non-final statics-only class corresponds  
roughly to single E objects with delegation:

   def foo { ... }

   def bar extends <import:foo> { ... }

I don't mean to say that there are sensible uses for this, but only  
that the restriction does not seem to be justified.

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>


_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

 « Return to Thread: Prettiness of Java statics classes: dropping the "make"

LightInTheBox - Buy quality products at wholesale price!