[e-lang] Prettiness of Java statics classes: dropping the "make"

Kevin Reid kpreid at mac.com
Sun May 11 09:53:21 CDT 2008


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:
>>
>>    ? def m := <import:java.lang.strictMath>
>>    # value: <strictMath>
>>
>>    ? <import:java.lang.makeStrictMath>
>>    # value: <strictMath>
>>
>> (Note that the import fqn is not "java.lang.StrictMath", as that  
>> should be a guard.)
>>
>> What do you think of this idea?
>
> What happens if the class begins with a lowercase letter?

Note that uncapitalized class names already introduce such a problem  
for the guard convention: <import:foo.Bar> should to the E programmer  
be a guard.

Currently, <import:foo.Bar> imports the object which exposes the  
static members ('StaticMaker'); this is deprecated in favor of  
foo.makeBar, and the plan is to transition to foo.Bar importing the  
type/guard of the class.

(MarkM, could you confirm that my claims fit your understanding of  
the plan as well?)


We could define <import:foo.bar>, <import:foo.makeBar>, and  
<import:foo.Bar> to look for either Bar or bar.

Are there Java libraries that use uncapitalized class names? Do we  
want to bother supporting them?

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




More information about the e-lang mailing list