I meant

Java package protection === D module private protection == C++ frind relationships

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c1m467$2ent$1@digitaldaemon.com...
>
> "Matthias Spycher" <matthias@coware.com> wrote in message
> news:c1lnes$1ope$1@digitaldaemon.com...
> | The idea is not to aggregate modules, but aggregate files, i.e. let a
single
> | module span multiple files. I should have noted that the auxilliary
files
> | a.b, b.d and c.d do not contain module delcarations and would not be
> | regarded as modules when m.d. is compiled.
> |
> | So a private declaration in a.d, b.d or c.d is visible in m.d. Similar
to
> | package protection in Java.
> |
> | Matthias
>
> Ah, I see what you mean. The "private is visible in module" is like
> C++ friend relationships. There isn't anything really like Java's
> package protection. C++ deals with this by making things public -
> or having lots of friends. I guess that is D's approach as well.
> I haven't written anything big enough in D to complain but I tend
> to agree it would be nice to have some more control over access
> than just private/public/protected/export.
>
> It could be as simple as adding "package" (or "modulepeer" or
> something) as a protection keyword meaning if the given module
> is foo.bar.baz then the symbol is visible in any module in foo.bar
> that imports baz. Adding a keyword is usually a last resort but we
> couldn't do what Java does and use no protection keyword to mean
> "package" because the default protection is "public".
>
> -Ben
>
>
>