Fix #2529: explicit protection package #3651
Dmitry Olshansky via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Fri Aug 22 08:06:13 PDT 2014
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
> On 8/19/2014 7:01 AM, Dicebot wrote:
> > Walter, now that release is out can you please state your
> opinion about
> > https://github.com/D-Programming-Language/dmd/pull/3651 ? It
> is blocking Phobos
> > module split and decoupling.
>
> I keep thinking there's gotta be a way to do this without
> language changes.
For what it's worth I don't care how things turn out w.r.t.
syntax, language extension or convention but the problem must be
solved.
The way I see the problem:
There must be nice and clean way to have internal stuff that is
invisible for user. Preferably this stuff must not be monolithic
and have form of package.
Example structure:
mod/package.d
mod/internal/bar.d
mod/...
I actually face it in Phobos right now, my blocked pull:
https://github.com/D-Programming-Language/phobos/pull/2412
Options:
1. Use current package attribute.
Disadvantages:
a) Must retain internals in the same package, user may still
import them no problem at all. At least it does not do much harm
as nothing is accessible.
b) Can't use std.mod.internal.bar 'package' stuff in std.mod
(upper one). That makes it next to unusable. Basically it means
we have to push internals up, instead of pushing them down.
2. Use separate public internal package.
Main disadvantage:
a) Now user may import and actually USE internal stuff.
b) Not only that but also internal methods of equally internal
structs and classes leak out. In other words: a struct defined in
internal module may never be exposed without some kind of
wrapping. Ugly and unnecessary complication.
I'd rather have a language feature, but whatever you guys invent
as 3rd option that doesn't suck will have my vote.
---
Dmitry Olshansky
More information about the Digitalmars-d-announce
mailing list