I think that the private import should be the default behavior for modules and public import should require explicit declaration.

The reason is that I think the public imports promote inappropriate module
linkages.  Consider modules A, B and C.  Both B and C use A. C uses B.
It happens that since B imports A, and C imports B that C gets A as a side
effect of importing B.  Now B changes it's implementation so that it no longer
uses A.  C has problems now because it lost it's import of A.

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bcct22$17el$1@digitaldaemon.com...
> I think that the private import should be the default behavior for modules
> and public import should require explicit declaration.
> The reason is that I think the public imports promote inappropriate module
> linkages.  Consider modules A, B and C.  Both B and C use A. C uses B.
> It happens that since B imports A, and C imports B that C gets A as a side
> effect of importing B.  Now B changes it's implementation so that it no
longer
> uses A.  C has problems now because it lost it's import of A.

Your reasoning is sound, but it would be backwards of the way public/private works in classes. Consistency is a tough thing to achieve <g>.

"Walter" <walter@digitalmars.com> wrote in news:bcgc7l$1c1o$1@digitaldaemon.com:

> 
> "Patrick Down" <Patrick_member@pathlink.com> wrote in message news:bcct22$17el$1@digitaldaemon.com...
>> I think that the private import should be the default behavior for
>> modules and public import should require explicit declaration.
>> The reason is that I think the public imports promote inappropriate
>> module linkages.  Consider modules A, B and C.  Both B and C use A. C
>> uses B. It happens that since B imports A, and C imports B that C
>> gets A as a side effect of importing B.  Now B changes it's
>> implementation so that it no
> longer
>> uses A.  C has problems now because it lost it's import of A.
> 
> Your reasoning is sound, but it would be backwards of the way public/private works in classes. Consistency is a tough thing to achieve <g>.

Is it really inconsistent?  I know there are many similarities between modules and classes but it would seem that they are also different enough to warrant a different set of rules.  It this case utility may be more important than any consistency you gain.

Patrick Down wrote:
> I think that the private import should be the default behavior for modules
> and public import should require explicit declaration.

What would be the result of:

  public
  {
     import b;
  }

If it's a public import, then that means the default protection scheme
is neither of the three, but a clause-tinged hybrid.  If it's a private
import, then that means you're ignoring the programmer's explicit
instructions.  I agree very strongly that you should use private imports
unless if you take on an API contract such as for a hub module, but I
don't think this policy translates into a mandate very gracefully, unless if we go all the way and default all symbols to private.

In article <bciolt$9a9$2@digitaldaemon.com>, Burton Radons says...

>If it's a public import, then that means the default protection scheme is neither of the three, but a clause-tinged hybrid.  If it's a private import, then that means you're ignoring the programmer's explicit instructions.  I agree very strongly that you should use private imports unless if you take on an API contract such as for a hub module, but I don't think this policy translates into a mandate very gracefully, unless if we go all the way and default all symbols to private.

That's why it's good for a unit to have an interface and an implementation section. Implementation can make its imports which are not used for the interfaced, but are not promoted to the importers.

-i.

In article <bciolt$9a9$2@digitaldaemon.com>, Burton Radons says...

>If it's a public import, then that means the default protection scheme is neither of the three, but a clause-tinged hybrid.  If it's a private import, then that means you're ignoring the programmer's explicit instructions.  I agree very strongly that you should use private imports unless if you take on an API contract such as for a hub module, but I don't think this policy translates into a mandate very gracefully, unless if we go all the way and default all symbols to private.

That's why it's good for a unit to have an interface and an implementation section. Implementation can make its imports which are not used for the interfaced, but are not promoted to the importers.

-i.

In article <bck5oa$1gb7$1@digitaldaemon.com>, Ilya Minkov says...
>
>In article <bciolt$9a9$2@digitaldaemon.com>, Burton Radons says...
>
>>If it's a public import, then that means the default protection scheme is neither of the three, but a clause-tinged hybrid.  If it's a private import, then that means you're ignoring the programmer's explicit instructions.  I agree very strongly that you should use private imports unless if you take on an API contract such as for a hub module, but I don't think this policy translates into a mandate very gracefully, unless if we go all the way and default all symbols to private.
>
>That's why it's good for a unit to have an interface and an implementation section. Implementation can make its imports which are not used for the interfaced, but are not promoted to the importers.

I agree. That makes it unambiguous, intuitive, and is probably quite easy to implement.

Another point I don't remember having read about here, is that
both Borland (Pascal/Delphi) and Sun (Java) have gotten
relatively few complaints during the years on how they
are resolving these issues.

I assume Walter has had some thoughts about why something new is required?

Georg Wrede wrote:
> In article <bck5oa$1gb7$1@digitaldaemon.com>, Ilya Minkov says...
> 
>>In article <bciolt$9a9$2@digitaldaemon.com>, Burton Radons says...
>>
>>
>>>If it's a public import, then that means the default protection scheme
>>>is neither of the three, but a clause-tinged hybrid.  If it's a private
>>>import, then that means you're ignoring the programmer's explicit
>>>instructions.  I agree very strongly that you should use private imports
>>>unless if you take on an API contract such as for a hub module, but I
>>>don't think this policy translates into a mandate very gracefully, unless if we go all the way and default all symbols to private.
>>
>>That's why it's good for a unit to have an interface and an implementation
>>section. Implementation can make its imports which are not used for the
>>interfaced, but are not promoted to the importers.
> 
> 
> I agree. That makes it unambiguous, intuitive, and is probably
> quite easy to implement.
> 
> Another point I don't remember having read about here, is that
> both Borland (Pascal/Delphi) and Sun (Java) have gotten
> relatively few complaints during the years on how they
> are resolving these issues.
> 
> I assume Walter has had some thoughts about why something new
> is required?

This sort of behaviour is already really easy to do.  Just use the C++ style access modifiers, ie:

   public:
   // interface

   private:
   // implementation

That's some powerful reasoning.

Get's my vote

"Ilya Minkov" <Ilya_member@pathlink.com> wrote in message news:bck5oa$1gb7$1@digitaldaemon.com...
> In article <bciolt$9a9$2@digitaldaemon.com>, Burton Radons says...
>
> >If it's a public import, then that means the default protection scheme is neither of the three, but a clause-tinged hybrid.  If it's a private import, then that means you're ignoring the programmer's explicit instructions.  I agree very strongly that you should use private imports unless if you take on an API contract such as for a hub module, but I don't think this policy translates into a mandate very gracefully, unless if we go all the way and default all symbols to private.
>
> That's why it's good for a unit to have an interface and an implementation section. Implementation can make its imports which are not used for the interfaced, but are not promoted to the importers.
>
> -i.
>
>