D - Module public/private
- Patrick Down <Patrick_member pathlink.com> Jun 13 2003
- "Walter" <walter digitalmars.com> Jun 14 2003
- Patrick Down <pat codemoon.com> Jun 15 2003
- Burton Radons <loth users.sourceforge.net> Jun 15 2003
- Ilya Minkov <Ilya_member pathlink.com> Jun 16 2003
- Ilya Minkov <Ilya_member pathlink.com> Jun 16 2003
- Georg Wrede <Georg_member pathlink.com> Jun 18 2003
- Andy Friesen <andy ikagames.com> Jun 18 2003
- "Matthew Wilson" <matthew stlsoft.org> Jul 08 2003
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
"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
Patrick Down <pat codemoon.com> "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
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
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
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
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
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
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