• Patrick Down (7/7) Jun 13 2003 I think that the private import should be the default behavior for modul...
• Walter (5/12) Jun 14 2003 longer
• Patrick Down (6/22) Jun 15 2003 Is it really inconsistent? I know there are many similarities
• Burton Radons (13/15) Jun 15 2003 What would be the result of:
• Ilya Minkov (5/12) Jun 16 2003 That's why it's good for a unit to have an interface and an implementati...
• Ilya Minkov (5/12) Jun 16 2003 That's why it's good for a unit to have an interface and an implementati...
• Georg Wrede (9/20) Jun 18 2003 I agree. That makes it unambiguous, intuitive, and is probably
• Andy Friesen (7/35) Jun 18 2003 This sort of behaviour is already really easy to do. Just use the C++
• Matthew Wilson (4/16) Jul 08 2003 That's some powerful reasoning.

Patrick Down <Patrick_member pathlink.com> writes:

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.

"Walter" <walter digitalmars.com> writes:

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

Patrick Down <pat codemoon.com> writes:

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

Burton Radons <loth users.sourceforge.net> writes:

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.

Ilya Minkov <Ilya_member pathlink.com> writes:

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.

Ilya Minkov <Ilya_member pathlink.com> writes:

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.

Georg Wrede <Georg_member pathlink.com> writes:

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?

Andy Friesen <andy ikagames.com> writes:

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

"Matthew Wilson" <matthew stlsoft.org> writes:

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.