Thoughts about modules

[Carlos Santander]

Kirk McDonald escribió:
> 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;
> 

I like that, and it would also be backwards compatible (no changes to import)

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

IIRC, what was suggested long ago was to use alias, but I don't remember where 
alias was supposed to be:

alias import x.y z;
import alias x.y z;
import x.y alias z;

> -- 
> Kirk McDonald


-- 
Carlos Santander Bernal