class Foo
{
protected int x;
class Bar
{
Foo f;
int method () { return f.x; }
}
}
Reports "class Foo member x is not accessible". Again, this way of
getting around data hiding is not adequate for cross-platform work. I
need either friend or the ability to cast off protection, preferably the
latter; I'm not going to make modules that are 13640 lines long!

class Foo
{
protected int x;
class Bar
{
Foo f;
int method () { return f.x; }
}
}
Reports "class Foo member x is not accessible". Again, this way of
getting around data hiding is not adequate for cross-platform work. I
need either friend or the ability to cast off protection, preferably the
latter; I'm not going to make modules that are 13640 lines long!

I
need either friend or the ability to cast off protection, preferably
the latter; I'm not going to make modules that are 13640 lines long!

I agree, I have already put classes together in the same file
for access reasons that I would have preferred to keep in separate
files.
But perhaps there are other solutions besides friend or casting
off protection. Let's restate the problem.
There are certain groups of classes that cooperate with one
another. For these types of classes there are really four
types of access desired.
1. public - The interface exposed to users outside of the group.
2. group - The interface exposed to other classes within the group.
3. protected - The interface exposed to just a class and it's children
4. private - The interface exposed to just a class itself
Now what's the problem? In D, group = module = single file and
putting all your code into a single file is not always the best
way to organize it.
So let's explore some ideas.
1. group = module != single file. We could introduce a new file type
like .di. When you import a module say foo it would still refer to
foo.d but foo.d could include several other files as part of the module
definition.
//foo.d
include bar.di
include baz.di
You could not import .di file and it would perhaps be illegal for
a .di to belong to another module.
2. Define a group attribute for classes
// foo.d
class Foo : group(FooBar)
{
group(FooBar): // Access specifier
int baz;
void glop();
}
// bar.d
class Bar : group(FooBar)
{
group(FooBar): // Access specifier
int taz;
void fred();
}
3. Same as #2 except not quite as controlled.
// foo.d
class Foo
{
// like friend except you don't
// have to list individual classes
group FooBar;
protected:
int baz;
void glop();
}
// bar.d
class Bar
{
// like friend except you don't
// have to list individual classes
group FooBar;
protected:
int taz;
void fred();
}
4. Classes that inherit for classes that share
the same module retain the same access rights
// foobar.d
class Foo { }
class Bar { }
// baxtaz.d
class Baz : Foo
{
// Taz can access because
// Baz and Taz's parents share
// the same module
protected int i;
}
class Taz : Bar
{
protected int j;
}
5. #4 is a little too uncontrolled perhaps a
module access specifier.
// foobar.d
class Foo { }
class Bar { }
// baxtaz.d
class Baz : Foo
{
// Taz can access because
// Baz and Taz's parents share
// the same module
module int i;
}
class Taz : Bar
{
module int j;
}

I
need either friend or the ability to cast off protection, preferably
the latter; I'm not going to make modules that are 13640 lines long!

I agree, I have already put classes together in the same file
for access reasons that I would have preferred to keep in separate
files.
But perhaps there are other solutions besides friend or casting
off protection. Let's restate the problem.
There are certain groups of classes that cooperate with one
another. For these types of classes there are really four
types of access desired.
1. public - The interface exposed to users outside of the group.
2. group - The interface exposed to other classes within the group.
3. protected - The interface exposed to just a class and it's children
4. private - The interface exposed to just a class itself
Now what's the problem? In D, group = module = single file and
putting all your code into a single file is not always the best
way to organize it.
So let's explore some ideas.
1. group = module != single file. We could introduce a new file type
like .di. When you import a module say foo it would still refer to
foo.d but foo.d could include several other files as part of the module
definition.
//foo.d
include bar.di
include baz.di
You could not import .di file and it would perhaps be illegal for
a .di to belong to another module.
2. Define a group attribute for classes
// foo.d
class Foo : group(FooBar)
{
group(FooBar): // Access specifier
int baz;
void glop();
}
// bar.d
class Bar : group(FooBar)
{
group(FooBar): // Access specifier
int taz;
void fred();
}
3. Same as #2 except not quite as controlled.
// foo.d
class Foo
{
// like friend except you don't
// have to list individual classes
group FooBar;
protected:
int baz;
void glop();
}
// bar.d
class Bar
{
// like friend except you don't
// have to list individual classes
group FooBar;
protected:
int taz;
void fred();
}
4. Classes that inherit for classes that share
the same module retain the same access rights
// foobar.d
class Foo { }
class Bar { }
// baxtaz.d
class Baz : Foo
{
// Taz can access because
// Baz and Taz's parents share
// the same module
protected int i;
}
class Taz : Bar
{
protected int j;
}
5. #4 is a little too uncontrolled perhaps a
module access specifier.
// foobar.d
class Foo { }
class Bar { }
// baxtaz.d
class Baz : Foo
{
// Taz can access because
// Baz and Taz's parents share
// the same module
module int i;
}
class Taz : Bar
{
module int j;
}