Thoughts about modules

[Kirk McDonald]

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.

While I'm proposing things, might I also propose

static import x;

to mean FQN import. (This would be the same as Sjoerd's proposed "import 
$ : foo.bar;".) It has the advantage of looking more like D code, I 
think. :-) The "as" keyword is also a good idea, as in

static import x.y as z;

--
Kirk McDonald