www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - package attribute. bug?

reply "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. 
Apr 01 2005
parent reply 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
Apr 01 2005
parent reply "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.
Apr 02 2005
parent reply 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.
Apr 02 2005
parent reply "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 }
Apr 02 2005
parent 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.
Apr 02 2005