Thoughts about modules

[Chris Nicholson-Sauls]

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.* ;

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.)

-- Chris Nicholson-Sauls