Thoughts about modules

[Kirk McDonald]

Chris Nicholson-Sauls wrote:
> Kirk McDonald wrote:
> 
>> Derek Parnell wrote:
>>
>>> On Thu, 29 Jun 2006 14:45:23 -0700, Kirk McDonald wrote:
>>>
>>>
>>>> Derek Parnell wrote:
>>>>
>>>>> Why is FQN syntax demonstrable better than the current shortcut 
>>>>> syntax?
>>>
>>>
>>>
>>>
>>>> ...
>>>> By making it mandatory, we can always know where any name comes 
>>>> from, whether they are being fully-qualified, or imported on their own.
>>>>
>>>> Now, for something like writefln, which is a well-known name that 
>>>> everyone will recognize instantly, this is a bit of a burden. You'd 
>>>> have to type it a whole extra time at the top of the file! 
>>>
>>>
>>>
>>>
>>> So to summarize ...
>>>
>>> Mandatory fully qualified names makes it simple for a code reader to 
>>> know
>>> in which module a member is located. But because that could be a 
>>> burden to
>>> the code writer, the alias (or something similar) can be used to 
>>> 'register'
>>> the FQN once in the code and allows the writer to use a short form of 
>>> the
>>> name.
>>>
>>> Anyhow, I tried this coding style on Build just now and ended up with
>>> this...
>>
>>
>>
>> [snipped some examples...]
>>
>>> import util.str;        // non-standard string routines.
>>> alias util.str.SetEnv           SetEnv;
>>> alias util.str.GetEnv           GetEnv;
>>> alias util.str.Expand           Expand;
>>> alias util.str.ExpandEnvVar     ExpandEnvVar;
>>> alias util.str.ends             ends;
>>> alias util.str.begins           begins;
>>> alias util.str.enquote          enquote;
>>> alias util.str.strip            ustrip;
>>> alias util.str.stripr           ustripr;
>>> alias util.str.IsLike           IsLike;
>>> alias util.str.YesNo            YesNo;
>>> alias util.str.TranslateEscapes TranslateEscapes;
>>
>>
>>
>> Note that with the shortcut that Python provides, this beomes the much 
>> less redundant:
>>
>> from util.str import SetEnv, GetEnv, Expand, ExpandEnvVar, ends, 
>> begins, enquote, ustrip, ustripr, IsLike, YesNo, TranslateEscapes;
>>
>> I don't feel I could endorse this practice unless the language 
>> supports it like this.
>>
>> I don't feel this is a really serious issue. :-) "private import" 
>> provides all the sandboxing I think is needed in the absence of C++ 
>> namespaces. This is just an orginizational nicety.
>>
>> -Kirk McDonald
> 
> 
> 
> I have worked with Python a bit, but it has been a few years so I don't 
> recall.  Is there an allowance for:
> 
> # from my.lib import Foo, Bar, Baz as x.* ;

You'd say:

 >>> import my.lib as x

Then you could access Foo as x.Foo, etc. There's no reason to 
selectively import parts of the module in this case, as they are all 
inside of the module's own (aliased) namespace, anyway.

> 
> Such that Foo is referred to as x.Foo, and so forth.  Also, I support 
> your idea of 'static import'.  It seems fitting, and it prevents having 
> to invent a new keyword.  (Yes, the poor 'static' keyword is starting to 
> get overloaded a bit, but I think its fair.)
> 

I just looked at the keywords already used as attributes and picked the 
one that seemed to work best. (It was a tossup between static and final, 
actually.)

> -- Chris Nicholson-Sauls

-Kirk McDonald