www.digitalmars.com/d/changelog.html

"Walter" <walter@digitalmars.com> wrote in message news:b32b8t$1suf$1@digitaldaemon.com...
>
> www.digitalmars.com/d/changelog.html
>
>

where is version 0.56 ?

ftp://ftp.digitalmars.com/dmd.zip

contains 0.55 beta (and the link on the download page is still  to ftp://ftp.digitalmars.com/dmdalpha.zip )

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b339n6$2oof$1@digitaldaemon.com...
> where is version 0.56 ?
>
> ftp://ftp.digitalmars.com/dmd.zip
>
> contains 0.55 beta (and the link on the download page is still  to ftp://ftp.digitalmars.com/dmdalpha.zip )

Oops! Should be fixed now. -Walter

templates with value items do not spot conflicts until instatiation
the following compiles, if the templates where one(R) not one (E R) then the
confilct would be spotted at compile time.

enum E { A, B }

template one( E R )
{
 void errfunc() { printf("one(1)\n"); }
 typedef void (*safeptr)() = &errfunc;
}

template one( E R )
{
 void errfunc() { printf("one(2)\n"); }
 typedef void (*safeptr)() = &errfunc;
}

int main( char[][] args )
{
 return 1;
}

"Walter" <walter@digitalmars.com> wrote in message news:b33ig7$30v4$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b339n6$2oof$1@digitaldaemon.com...
> > where is version 0.56 ?
> >
> > ftp://ftp.digitalmars.com/dmd.zip
> >
> > contains 0.55 beta (and the link on the download page is still  to ftp://ftp.digitalmars.com/dmdalpha.zip )
>
> Oops! Should be fixed now. -Walter
>
>

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!

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:b3aqni$fd9$1@digitaldaemon.com...
> 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!

It should be accessible from Bar, it's a compiler bug.

Burton Radons <loth@users.sourceforge.net> wrote in
news:b3aqni$fd9$1@digitaldaemon.com:

>   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 like C#'s internal scope.  Internal members are public within the assembly (package), private otherwise.

Patrick Down wrote:
> Burton Radons <loth@users.sourceforge.net> wrote in
> news:b3aqni$fd9$1@digitaldaemon.com:  
> 
>>  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;
> }
> 
>