• Andrew Fedoniouk (23/23) Apr 01 2005 "Package extends private so that package members can be accessed f...
• Derek Parnell (8/39) Apr 01 2005 I don't know how to reproduce this issue. What are the full file and pat...
• Andrew Fedoniouk (35/35) Apr 02 2005 Beg my pardon, this is more precise definition.
• Mike Parker (4/29) Apr 02 2005 myproject and myproject.impl are two distinct packages. So the dummy
• Andrew Fedoniouk (17/20) Apr 02 2005 Then I would like to see more clear definition of
• Mike Parker (4/32) Apr 02 2005 I never tried this before because I just 'knew' it wouldn't work. If

"Andrew Fedoniouk" <news terrainformatica.com> writes:

<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. 

Derek Parnell <derek psych.ward> writes:

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

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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.

Mike Parker <aldacron71 yahoo.com> writes:

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.

"Andrew Fedoniouk" <news terrainformatica.com> writes:

 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
}

Mike Parker <aldacron71 yahoo.com> writes:

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.