www.digitalmars.com         C & C++   DMDScript  

D - Module public/private

reply 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.
Jun 13 2003
next sibling parent reply "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

 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>.
Jun 14 2003
parent 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 

 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.
Jun 15 2003
prev sibling parent reply 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.
Jun 15 2003
next sibling parent 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.
Jun 16 2003
prev sibling parent reply 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.
Jun 16 2003
next sibling parent reply 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?
Jun 18 2003
parent 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
Jun 18 2003
prev sibling parent "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.

Jul 08 2003