In article <dfn1j0$fd4$1@digitaldaemon.com>, pragma says...
>
>This got me thinking.  What if we keep the behavior of import, but allow for a more verbose syntax when we want less generalized behavior.
>
>> import <module> as <namespace name>
>
>It would function along the lines of the current guidelines for aliasing module definitions, but it would affect the entire import.  Plus, we could define this as saying that all the symbols imported this way *must* use the FQN prefixed by the 'namespace name' provided.
..
>Does this solve the problem at hand?

While a finer-grained control of symbol visibility would be nice, this suggestion seems like a good compromise.  And since the mixin syntax already works this way (I think), extending it to import seems appropriate.


Sean

Ben Hinkle wrote:
>>>>In this situation, a more concrete problem arises for example when you have an IDE with code autocompletion.
>>>
>>>I don't understand. Can you give more details?
>>>
>>
>>An example from the previous thread, slighty modified:
>>
>>As for the IDE code-completion, to be more clear let me give an example of what would happen with D currently:
>>
>>  module foobar;
>>    void DoStuff() { ... }
>>    void DoStuff2() { ... }
>>---------------------------------------
>>  module whatever;
>>  import foobar;
>>
>>  void DoThings() { ... }
>>  void DoMoreThings() { ... }
>>
>>  int func(){
>>    ...
>>    Do| <- press ctrl-space here for code-completion
>>  }
> 
> 
> The IDE can have a preference to toggle between showing all symbols and symbols in the current module. By default it would show everything (since that's how D works normally) but if one wants to only work with local symbols one can restrict what gets shown.
> 
> 
What makes you think one will want to work the same way (by local names or FQN) with all entities? That is certainly not the case. And so, consider the following where one uses 3 ways to access entities:

  module whatever;

  import xpto; // wants acces by FQN
  import misc; // wants access by base/local name;
  import foobars.foobarA; // wants access by "middle" name;
  alias foobars.foobarA foobarA; // bad hack for "using" packages.

  ...

  xpto.doStuff		// xpto.doStuff
  something 		// misc.something
  foobarA.doStuff	// foobars.foobarA.doStuff

The IDE code completion will be filled with clutter of other access pathways. Granted, the third way (/using/ hack) may not be very common, but the other two will, and still mess up the IDE.


-- 
Bruno Medeiros
Computer Science/Engineering student

pragma wrote:
> This got me thinking.  What if we keep the behavior of import, but allow for a
> more verbose syntax when we want less generalized behavior.
> 
> 
>>import <module> as <namespace name>
> 
> 
> It would function along the lines of the current guidelines for aliasing module
> definitions, but it would affect the entire import.  Plus, we could define this
> as saying that all the symbols imported this way *must* use the FQN prefixed by
> the 'namespace name' provided.
> 
> 
I can see a bit of usefullness for that feature, but not as a replacement for a fqn-import statement. Why? Because the equivalent import-as to a fqn-import statement is tediously unnecessarily longer to write:

  importm foobars.foobarABC;
vs.
  import foobars.foobarABC as foobars.foobarABC;



-- 
Bruno Medeiros
Computer Science/Engineering student

Sean Kelly wrote:
> In article <dflce3$21vp$1@digitaldaemon.com>, Bruno Medeiros says...
> 
>>1) It is conceptualy wrong to have this statement make entities acessible in two ways, since almost allways you will want to use only one way. It is especially worse when it is by FQN that you want to access the module's entities, as the unwanted base names start polluting the current module scope.
> 
> 
> But sometimes you want the base names to pollute the module's scope.  An obvious
> example are the standard C and POSIX headers.  Many of them are required to
> expose symbols defined in other modules.  Since private import/alias doesn't
> work (it's seen as a re-declaration from importing modules), public import is
> the only option.  I like your suggestions, but there must be a way to import one
> module's symbols into another, even if it is explicit (through 'using', for
> example).
> 
> 
> Sean
> 
> 
Are you sure you quoted the right paragraph? I'm not sure about what and which of two different things you are talking about:
If either about the base-import vs fqn-import (and the fact that currently one cannot do one of them separately from the other, and thus the "polution"), or about private imports vs public imports.
And what exactly is it that "there must be a way to", but you can't do on my suggestions?

-- 
Bruno Medeiros
Computer Science/Engineering student

Bruno Medeiros wrote:
> pragma wrote:
> 
>> This got me thinking.  What if we keep the behavior of import, but allow for a
>> more verbose syntax when we want less generalized behavior.
>>
>>
>>> import <module> as <namespace name>
>>
>>
>>
>> It would function along the lines of the current guidelines for aliasing module
>> definitions, but it would affect the entire import.  Plus, we could define this
>> as saying that all the symbols imported this way *must* use the FQN prefixed by
>> the 'namespace name' provided.
>>
>>
> I can see a bit of usefullness for that feature, but not as a replacement for a fqn-import statement. Why? Because the equivalent import-as to a fqn-import statement is tediously unnecessarily longer to write:
> 
>   importm foobars.foobarABC;
> vs.
>   import foobars.foobarABC as foobars.foobarABC;

Granted, but that's just *once* for the import statement.  Since adopting this form would lock you into using an FQN for every member of the imported module, it's not the last time you're going to type that out. ;)

Also, there's no reason why you can't just abbreviate the module name, along the lines of what's been proposed by using alias statement workarounds:

> import foobars.foobarABC as foobarABC;

-- 
- EricAnderton at yahoo

On Thu, 08 Sep 2005 19:28:31 -0700, pragma wrote:

Hey Eric, you want to check your computer's clock setting? You posts arrive about 13 hours into the future.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 9:34:03 AM

In article <dfqg3h$jqu$1@digitaldaemon.com>, Bruno Medeiros says...
>
>Sean Kelly wrote:
>> In article <dflce3$21vp$1@digitaldaemon.com>, Bruno Medeiros says...
>> 
>>>1) It is conceptualy wrong to have this statement make entities acessible in two ways, since almost allways you will want to use only one way. It is especially worse when it is by FQN that you want to access the module's entities, as the unwanted base names start polluting the current module scope.
>> 
>> 
>> But sometimes you want the base names to pollute the module's scope.  An obvious example are the standard C and POSIX headers.  Many of them are required to expose symbols defined in other modules.  Since private import/alias doesn't work (it's seen as a re-declaration from importing modules), public import is the only option.  I like your suggestions, but there must be a way to import one module's symbols into another, even if it is explicit (through 'using', for example).
>> 
>Are you sure you quoted the right paragraph? I'm not sure about what and
>which of two different things you are talking about:
>If either about the base-import vs fqn-import (and the fact that
>currently one cannot do one of them separately from the other, and thus
>the "polution"), or about private imports vs public imports.
>And what exactly is it that "there must be a way to", but you can't do
>on my suggestions?

Nothing :)  I merely didn't want this necessity to be overlooked.  For what it's worth, I like Eric's suggestion the best.  That is, to allow for an optional namespace specifier on import statements (similar to mixins):

import mod mod_a;
import mod mod_b;

I like the the suggestion of 'as', but then the mixin syntax should be changed as well.  This offers all the features of your Proposal 2 (which I liked the best of the four) but keeps default behavior unchanged, which I think is important.  Also, I'm not sure I like the impact that an abbreviated namespace system would have on D.  It would really have to be all or nothing to keep from being unwieldy, and I like D's visibility rules better than those in C++.


Sean

Derek Parnell wrote:
> On Thu, 08 Sep 2005 19:28:31 -0700, pragma wrote:
> 
> Hey Eric, you want to check your computer's clock setting? You posts arrive
> about 13 hours into the future.
> 

Heh, thanks for letting me know Derek. :)

Looks like my settins were in the wrong timezone.

-- 
- EricAnderton at yahoo

Well, I still didn't got Walter's view on this issue. There is little more I can say other than restate that the shortcomings of the current situation.
So heed these words, this will either be fixed in time, or it will haunt D until so.


-- 
Bruno Medeiros
Computer Science/Engineering student