www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Conflict with private symbol from an imported module

reply "Nicolas Sicard" <dransic gmail.com> writes:
Hi,

I known this has been discussed before, and there still is an 
open issue in bugzilla 
(https://d.puremagic.com/issues/show_bug.cgi?id=1238). Is it 
considered a feature or a bug?

Thanks
Jan 23 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
I think it is one of the most major problems with the whole 
module system right now...
Jan 23 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 23 January 2014 at 17:06:17 UTC, Nicolas Sicard 
wrote:

 Hi,

 I known this has been discussed before, and there still is an 
 open issue in bugzilla 
 (https://d.puremagic.com/issues/show_bug.cgi?id=1238). Is it 
 considered a feature or a bug?

 Thanks


Modules are broken in several ways: 
https://d.puremagic.com/issues/show_bug.cgi?id=314
Jan 23 2014
parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Thursday, 23 January 2014 at 17:29:08 UTC, Gary Willoughby 
wrote:

 On Thursday, 23 January 2014 at 17:06:17 UTC, Nicolas Sicard 
 wrote:

 Hi,

 I known this has been discussed before, and there still is an 
 open issue in bugzilla 
 (https://d.puremagic.com/issues/show_bug.cgi?id=1238). Is it 
 considered a feature or a bug?

 Thanks


 Modules are broken in several ways: 
 https://d.puremagic.com/issues/show_bug.cgi?id=314


It sure is broken. But I wondered if it would be let aside. I say 
this because I think I remember reading (from Walter?) that it 
would need a significant re-implementation to fix it.
Jan 23 2014
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 23, 2014 at 05:38:03PM +0000, Nicolas Sicard wrote:

 On Thursday, 23 January 2014 at 17:29:08 UTC, Gary Willoughby wrote:

On Thursday, 23 January 2014 at 17:06:17 UTC, Nicolas Sicard
wrote:

Hi,

I known this has been discussed before, and there still is an
open issue in bugzilla
(https://d.puremagic.com/issues/show_bug.cgi?id=1238). Is it
considered a feature or a bug?

Thanks


Modules are broken in several ways:
https://d.puremagic.com/issues/show_bug.cgi?id=314


 
 It sure is broken. But I wondered if it would be let aside. I say
 this because I think I remember reading (from Walter?) that it would
 need a significant re-implementation to fix it.


Reimplementation or not, I consider this a major bug. This has actually
happened to me with Phobos:

1) In an earlier version of D, I had a module stack.d that declares a
public symbol 'Stack', and another module mod.d that imports module
stack and also std.regex.

2) In the meantime, Dmitri revised the implementation of std.regex and
in the process introduced a *private* symbol Stack. These changes are
merged into Phobos and included in the subsequent release.

3) I upgrade dmd to the subsequent release, and suddenly my code has a
compile error, because the *public* symbol stack.Stack conflicts with
the *private* symbol std.regex.Stack.

Not only this is a major annoyance, it also breaks encapsulation because
anytime you introduce new private symbols to your library module, you
could, in theory, be breaking random user code due to these conflicts.
Why should user code care that new *private* symbols were introduced to
the module?? Such implementation details ought to be invisible to the
outside world. Yet currently, user code has to disambiguate these
conflicting symbols in order to compile.

This travesty needs to be fixed, otherwise D will just remain a laughing
stock of other languages.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler
Jan 23 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 23.01.2014 19:16, schrieb H. S. Teoh:

 On Thu, Jan 23, 2014 at 05:38:03PM +0000, Nicolas Sicard wrote:

 On Thursday, 23 January 2014 at 17:29:08 UTC, Gary Willoughby wrote:

 On Thursday, 23 January 2014 at 17:06:17 UTC, Nicolas Sicard
 wrote:

 Hi,

 I known this has been discussed before, and there still is an
 open issue in bugzilla
 (https://d.puremagic.com/issues/show_bug.cgi?id=1238). Is it
 considered a feature or a bug?

 Thanks


 Modules are broken in several ways:
 https://d.puremagic.com/issues/show_bug.cgi?id=314


 It sure is broken. But I wondered if it would be let aside. I say
 this because I think I remember reading (from Walter?) that it would
 need a significant re-implementation to fix it.


 Reimplementation or not, I consider this a major bug. This has actually
 happened to me with Phobos:

 1) In an earlier version of D, I had a module stack.d that declares a
 public symbol 'Stack', and another module mod.d that imports module
 stack and also std.regex.

 2) In the meantime, Dmitri revised the implementation of std.regex and
 in the process introduced a *private* symbol Stack. These changes are
 merged into Phobos and included in the subsequent release.

 3) I upgrade dmd to the subsequent release, and suddenly my code has a
 compile error, because the *public* symbol stack.Stack conflicts with
 the *private* symbol std.regex.Stack.

 Not only this is a major annoyance, it also breaks encapsulation because
 anytime you introduce new private symbols to your library module, you
 could, in theory, be breaking random user code due to these conflicts.
 Why should user code care that new *private* symbols were introduced to
 the module?? Such implementation details ought to be invisible to the
 outside world. Yet currently, user code has to disambiguate these
 conflicting symbols in order to compile.

 This travesty needs to be fixed, otherwise D will just remain a laughing
 stock of other languages.


 T



Fully agree.

- Private symbols should not be exposed

- It should be possible to distribute binary modules with the 
corresponding .di file.


--
Paulo
Jan 23 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
There is a pull from Martin that implements new symbol access 
resolution rules and old DIP of mine on same topic. Those do 
contradict each other though as we seem to disagree on quite on 
rules related to template instances / alias arguments. Martin has 
the obvious benefit of actually having an implementation of 
course, I don't remember what is blocking its approval.

Everything related to alias template arguments is pretty much the 
main difficulty and discussion point when it comes to finally 
fixing this terribly annoying bug.
Jan 23 2014