<cite>"Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages."</cite>

Reading this I am trying to implement following:

There are two modules
--------------------
module foo;

class Foo {
    package int dummy;
}

--------------------
module foo.bar;

int Bar(  )
{
    Foo f = new Foo();
    f.dummy = 123; // ****
}
--------------------

At the line **** I am getting

"class foo.Foo member dummy is not accessible"

Is it just a bug? Or am I too optimistic?
Thanks in advance....

Andrew.

On Fri, 1 Apr 2005 22:17:07 -0800, Andrew Fedoniouk wrote:

> <cite>"Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages."</cite>
> 
> Reading this I am trying to implement following:
> 
> There are two modules
> --------------------
> module foo;
> 
> class Foo {
>     package int dummy;
> }
> 
> --------------------
> module foo.bar;
> 
> int Bar(  )
> {
>     Foo f = new Foo();
>     f.dummy = 123; // ****
> }
> --------------------
> 
> At the line **** I am getting
> 
> "class foo.Foo member dummy is not accessible"
> 
> Is it just a bug? Or am I too optimistic?
> Thanks in advance....
> 
I don't know how to reproduce this issue. What are the full file and path names of the two modules? I can't see any 'import' statements, or is that what you are trying to see if D can do?

-- 
Derek Parnell
Melbourne, Australia
2/04/2005 4:53:47 PM

Beg my pardon, this is more precise definition.

---/myproject/foo.d-----------------

module myproject.foo;

class Foo {
   // should be visible for
   // all functions in myproject.*
    package int dummy;
}

---/myproject/impl/bar.d-------------

module myproject.impl.bar;
import myproject.foo;

int Bar(  )
{
     Foo f = new Foo();
     f.dummy = 123; // here is problem!
}

what is the package here? I guess "myproject"... BTW, an I right here?

=================================
In fact I want to separate logical class
from its possible implementations (e.g. on  different plaforms)

So I have something like

ui/graphics.d   ( class Graphics  )
ui/win32/graphicsImpl.d ( Native Graphics functions )
ui/macosx/graphicsImpl.d ( Native Graphics functions )

I would like to have some methods / vars in Graphics
accessible only from inner package classes / functions e.g. from
NativeGraphics*** methods.
Seems like no way in D so far.

Standard D approach (version()...) looks a bit ugly in my case.
E.g. Graphics is a bunch of HDC related methods and stuff from Quartz and
XWindow...
One file is not acceptable as different developers are coding different
platforms
at the same time.

Andrew.

Andrew Fedoniouk wrote:
> Beg my pardon, this is more precise definition.
> 
> ---/myproject/foo.d-----------------
> 
> module myproject.foo;
> 
> class Foo {
>    // should be visible for
>    // all functions in myproject.*
>     package int dummy;
> }
> 
> ---/myproject/impl/bar.d-------------
> 
> module myproject.impl.bar;
> import myproject.foo;
> 
> int Bar(  )
> {
>      Foo f = new Foo();
>      f.dummy = 123; // here is problem!
> }
> 
> what is the package here? I guess "myproject"... BTW, an I right here?
> 

myproject and myproject.impl are two distinct packages. So the dummy method cannot be visible to anything in myproject.impl, only to other modules in myproject.

> myproject and myproject.impl are two distinct packages. So the dummy method cannot be visible to anything in myproject.impl, only to other modules in myproject.

Then I would like to see more clear definition of
the package. Is it just a "folder" or "subtree"?

BTW: following works just perfectly:

---/myproject/foo.d-------------

module myproject.foo;

// Is visible for
// all functions in myproject.*

package void Foo()
{

}

---/myproject/impl/bar.d-------------

module myproject.impl.bar;
import myproject.foo;

int Bar(  )
{
      Foo(); // no complains here
}

Andrew Fedoniouk wrote:

> 
> Then I would like to see more clear definition of
> the package. Is it just a "folder" or "subtree"?
> 
> BTW: following works just perfectly:
> 
> ---/myproject/foo.d-------------
> 
> module myproject.foo;
> 
> // Is visible for
> // all functions in myproject.*
> 
> package void Foo()
> {
> 
> }
> 
> ---/myproject/impl/bar.d-------------
> 
> module myproject.impl.bar;
> import myproject.foo;
> 
> int Bar(  )
> {
>       Foo(); // no complains here
> }
> 

I never tried this before because I just 'knew' it wouldn't work. If this is the intended behavior, that's great. And we do need a definition that accurately reflects this in the docs.