Yep, that's the question. Do any of the protection modifiers work now? I've been experimenting with public, protected and private and the way I see it, they're not working. Any thoughts on this?

In article <dn3u5e$ndb$1@digitaldaemon.com>, Antti Oja says...
>
>Yep, that's the question. Do any of the protection modifiers work now? I've been experimenting with public, protected and private and the way I see it, they're not working. Any thoughts on this?

As I recall (my knowledge of D may be pretty out of date) protection modifiers don't apply within the same module - everything in a module can access everything else in that module. Last time I looked they also didn't work with structs, but I think that was accepted as a bug and should have been fixed by now.

In article <dn413e$qgm$1@digitaldaemon.com>, Mike Capp says...
>
>As I recall (my knowledge of D may be pretty out of date) protection modifiers don't apply within the same module - everything in a module can access everything else in that module. Last time I looked they also didn't work with structs, but I think that was accepted as a bug and should have been fixed by now.
>

Thanks for your input. I'll look into it :)

- Antti

It all works as expected except in two cases:

1) you dereference a private static member of a struct, via the struct name. This appears to be a bug. Referencing via a struct instance correctly issues an error about the non-visibility.

2) you make reference to a private attribute or member defined within the same module. This is by design and, IMO, is a really nice feature. Those who don't like this aspect can use seperate modules instead?

- Kris

"Antti Oja" <Antti_member@pathlink.com> wrote in message news:dn3u5e$ndb$1@digitaldaemon.com...
> Yep, that's the question. Do any of the protection modifiers work now?
> I've been
> experimenting with public, protected and private and the way I see it,
> they're
> not working. Any thoughts on this?
>
> 

"Kris" <fu@bar.com> wrote in message news:dn4jcq$1h41$1@digitaldaemon.com...
> It all works as expected except in two cases:
>
> 1) you dereference a private static member of a struct, via the struct name. This appears to be a bug. Referencing via a struct instance correctly issues an error about the non-visibility.
>
> 2) you make reference to a private attribute or member defined within the same module. This is by design and, IMO, is a really nice feature. Those who don't like this aspect can use seperate modules instead?

3) You try to access private / protected members of inner classes.  Despite their being in the same module for obvious reasons, you cannot access those members.  Confusing.

Kris wrote:
> It all works as expected except in two cases:
> 
> 1) you dereference a private static member of a struct, via the struct name. This appears to be a bug. Referencing via a struct instance correctly issues an error about the non-visibility.
> 
This is part of more general issue, exposed recently:
Accessing any private named entity is allowed if you access by it's parent entity.

  module foomod;
  private void privfunc() {}
---
  import foomod;
  ...
  {
    privfunc();         // Illegal
    foomod.privfunc();  // Allowed
  }


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."