http://d.puremagic.com/issues/show_bug.cgi?id=206

           Summary: attributes private, package, etc appear to be ignored
           Product: D
           Version: 0.160
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: critical
          Priority: P1
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: someidiot@earthlink.net


Attributes marked as 'private' to one module are perfectly visible to all others. It appears 'package' has a similar problem. Perhaps 'protected' too ?


-- 

d-bugmail@puremagic.com schrieb am 2006-06-18:
> http://d.puremagic.com/issues/show_bug.cgi?id=206

> Attributes marked as 'private' to one module are perfectly visible to all others. It appears 'package' has a similar problem. Perhaps 'protected' too ?

Could you please back-up you bug report with a quote from the documentation? - As far as I'm aware, D doesn't care about visibility but accessibility...

Thomas

http://d.puremagic.com/issues/show_bug.cgi?id=206





------- Comment #1 from ddparnell@bigpond.com  2006-06-18 19:45 -------
The original bug report uses the word 'visibility' when in fact 'accessibility' was meant.

Here is a code example that compiles okay but it should not...

//----- file qwerty.d ----------
module qwerty;
private void  foo() {}
// ---EOF---

//----- file mod.d -------------
module mod;
private import qwerty;
private void bar(){}
// ---EOF---

//----- file test.d -------------
import mod;
void main()
{
   mod.bar();      // 'bar' is supposed to be private to mod.
   qwerty.foo();   // 'qwerty' is supposed to be private to mod.
                   // 'foo' is supposed to be private to qwerty.
}
// ---EOF---

Compile this with ...

  dmd test.d mod.d qwerty.d

If you change the test.d file to remove the module qualifiers, it fails to compile, which is correct.

//----- file test2.d -------------
import mod;
void main()
{
   bar();
   foo();
}
// ---EOF---

Now when compiled we get ....

  test2.d: module test2 mod.bar is private
  test2.d(5): undefined identifier foo
  test2.d(5): function expected before (), not foo of type int


-- 

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> d-bugmail@puremagic.com schrieb am 2006-06-18:
> 
>>http://d.puremagic.com/issues/show_bug.cgi?id=206
> 
> 
>>Attributes marked as 'private' to one module are perfectly visible to all
>>others. It appears 'package' has a similar problem. Perhaps 'protected' too ?
> 
> 
> Could you please back-up you bug report with a quote from the
> documentation? - As far as I'm aware, D doesn't care about visibility
> but accessibility...
> 
> Thomas

I think we call all sleep safely tonight, knowing that the word "visibility" - when discussed in terms of private, package, public, and protected attributes - is both oft-used and perfectly valid terminology.

Don't know what documentation you might be referring to, Thomas -- but hopefully this particular report refers to something sufficiently rudimentary that it will be correctly understood? I do hope so.

http://d.puremagic.com/issues/show_bug.cgi?id=206


daiphoenix@lycos.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Comment #2 from daiphoenix@lycos.com  2006-06-19 06:43 -------
Duplicate...

*** This bug has been marked as a duplicate of 48 ***


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=206


someidiot@earthlink.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |




------- Comment #3 from someidiot@earthlink.net  2006-06-19 13:33 -------
This is *not* a duplicate of #48 -- read the descriptions carefully. #48 actually has the basic visibility operable and enabled (in march 2006), but allows one to step around visibility by fully qualifiying. Since then, the basic visibility mechanism has broken down completely.


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=206
> 
> 
> someidiot@earthlink.net changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|DUPLICATE                   |
> 
> 
> 
> 
> ------- Comment #3 from someidiot@earthlink.net  2006-06-19 13:33 -------
> This is *not* a duplicate of #48 -- read the descriptions carefully. #48
> actually has the basic visibility operable and enabled (in march 2006), but
> allows one to step around visibility by fully qualifiying. Since then, the
> basic visibility mechanism has broken down completely.
> 
> 


It's somewhat annoying when someone goes in and starts removing active bug reports; especially when they apparently don't even understand the problem described. This kind of behaviour tends to dissuade the submission of reports in the first place.

What can be done about this sort of thing?

http://d.puremagic.com/issues/show_bug.cgi?id=206





------- Comment #4 from deewiant@gmail.com  2006-06-19 13:39 -------
Bruno's comment in Bug 48 addresses this issue as well, however. And it's likely they're both the same issue, caused by the same code in the compiler. I'd argue that we stick with 48.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=206


someidiot@earthlink.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW




------- Comment #5 from someidiot@earthlink.net  2006-06-19 13:56 -------
It's a possibility, but a bit vague for my tastes. I'd argue that (a) Derek's
examples are notably superior, (b) the report is certainly related at some
level, but clearly identifies a different aspect (in the example) than the
earlier report, and (c) the more reports on this, the better :)


-- 

kris wrote:
> d-bugmail@puremagic.com wrote:
>> http://d.puremagic.com/issues/show_bug.cgi?id=206
>>
>> someidiot@earthlink.net changed:
>>
>>            What    |Removed                     |Added
>> ---------------------------------------------------------------------------- 
>>
>>              Status|RESOLVED                    |REOPENED
>>          Resolution|DUPLICATE                   |
>>
>> ------- Comment #3 from someidiot@earthlink.net  2006-06-19 13:33 -------
>> This is *not* a duplicate of #48 -- read the descriptions carefully. #48
>> actually has the basic visibility operable and enabled (in march 2006), but
>> allows one to step around visibility by fully qualifiying. Since then, the
>> basic visibility mechanism has broken down completely.
> 
> It's somewhat annoying when someone goes in and starts removing active bug reports; especially when they apparently don't even understand the problem described. This kind of behaviour tends to dissuade the submission of reports in the first place.
> 
> What can be done about this sort of thing?

IMO only the responsible party (Walter, for DMD) or the submitter should alter a ticket's status.  I appreciate the effort of others try and keep things all neat and tidy, but I'm not sure things have gotten to the point where this sort of help is truly necessary.  If you suspect a ticket is a duplicate, perhaps it would be more appropriate to post something to the effect here and let the submitter decide?


Sean