www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need more fine-grained access control

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Is there a mechanism for making things private to the current class 
only, and _not_ the package.

For example, in the expansion to Open-RJ we need to be able to 
prevent the Record class from having write access to any of the 
members of the Field class, in order to ensure there are no 
erroneous breaking of the immutable characteristics of the Field 
type. But because they are - have to be - defined in the same 
package, anything can scribble on anything else. Horrid.

How about a

    "private private"

qualifier. (Of course, I don't think anything should be able to see 
inside anything else by default, but that's not going to change, so 
this is the next best thing.)

Thoughts?
Apr 30 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew schrieb am Sun, 1 May 2005 16:36:05 +1000:

 Is there a mechanism for making things private to the current class 
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to 
 prevent the Record class from having write access to any of the 
 members of the Field class, in order to ensure there are no 
 erroneous breaking of the immutable characteristics of the Field 
 type. But because they are - have to be - defined in the same 
 package, anything can scribble on anything else. Horrid.


What is the problem with using 2+ modules in the same package?

<snip>

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFCdIq43w+/yD4P9tIRAiUvAKCt12H2xyyMbyPBIzYI05XGIyaI9wCdG54V
MZMvAChaQOntufIuZrRFkM4=
=l+P0
-----END PGP SIGNATURE-----
May 01 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
news:peeek2-la7.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Matthew schrieb am Sun, 1 May 2005 16:36:05 +1000:

 Is there a mechanism for making things private to the current
 class
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to
 prevent the Record class from having write access to any of the
 members of the Field class, in order to ensure there are no
 erroneous breaking of the immutable characteristics of the Field
 type. But because they are - have to be - defined in the same
 package, anything can scribble on anything else. Horrid.


 What is the problem with using 2+ modules in the same package?


I can't say, as I don't know what that means. Can you elucidate?
May 01 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew schrieb am Sun, 1 May 2005 18:00:06 +1000:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message
 news:peeek2-la7.ln1 lnews.kuehne.cn...

 Matthew schrieb am Sun, 1 May 2005 16:36:05 +1000:

 Is there a mechanism for making things private to the current
 class
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to
 prevent the Record class from having write access to any of the
 members of the Field class, in order to ensure there are no
 erroneous breaking of the immutable characteristics of the Field
 type. But because they are - have to be - defined in the same
 package, anything can scribble on anything else. Horrid.


 What is the problem with using 2+ modules in the same package?


 I can't say, as I don't know what that means. Can you elucidate?


Modules b and c are part of the same package a:

module a.b;
module a.c;

Now you can use the access attribute "package" for more fine-grained control.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCdJAo3w+/yD4P9tIRAkXjAKDO34wtw/3KQ9wysopQCQsYCf3Z6gCfRWJ4
08jmz4fs97zYSoLuU0vbSv8=
=iKCB
-----END PGP SIGNATURE-----
May 01 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message 
news:8qfek2-la7.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Matthew schrieb am Sun, 1 May 2005 18:00:06 +1000:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in 
 message
 news:peeek2-la7.ln1 lnews.kuehne.cn...

 Matthew schrieb am Sun, 1 May 2005 16:36:05 +1000:

 Is there a mechanism for making things private to the current
 class
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to
 prevent the Record class from having write access to any of the
 members of the Field class, in order to ensure there are no
 erroneous breaking of the immutable characteristics of the 
 Field
 type. But because they are - have to be - defined in the same
 package, anything can scribble on anything else. Horrid.


 What is the problem with using 2+ modules in the same package?


 I can't say, as I don't know what that means. Can you elucidate?


 Modules b and c are part of the same package a:

 module a.b;
 module a.c;

 Now you can use the access attribute "package" for more 
 fine-grained control.


I'm think I'm getting hints at what you mean, but need more info. 
Can you show with a bit more code?
May 01 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 2 May 2005 14:18:00 +1000, Matthew wrote:


 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message 
 news:8qfek2-la7.ln1 lnews.kuehne.cn...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Matthew schrieb am Sun, 1 May 2005 18:00:06 +1000:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in 
 message
 news:peeek2-la7.ln1 lnews.kuehne.cn...

 Matthew schrieb am Sun, 1 May 2005 16:36:05 +1000:

 Is there a mechanism for making things private to the current
 class
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to
 prevent the Record class from having write access to any of the
 members of the Field class, in order to ensure there are no
 erroneous breaking of the immutable characteristics of the 
 Field
 type. But because they are - have to be - defined in the same
 package, anything can scribble on anything else. Horrid.


 What is the problem with using 2+ modules in the same package?


 I can't say, as I don't know what that means. Can you elucidate?


 Modules b and c are part of the same package a:

 module a.b;
 module a.c;

 Now you can use the access attribute "package" for more 
 fine-grained control.


 
 I'm think I'm getting hints at what you mean, but need more info. 
 Can you show with a bit more code?


All identifiers in a single file are visible to any code also in the same
file. This is regardless of any 'private' or 'package' attribute.

All 'private' identifiers in a file are hidden to code that is in any other
files.

All 'package' identifiers in a file are hidden to code that is in any other
file that is also in another directory. They are not hidden to code in
files that are in the same directory.

All other identifies are visible to code in any file in any directory.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v2.05 released 02/May/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
2/05/2005 3:03:10 PM
May 01 2005
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew schrieb am Mon, 2 May 2005 14:18:00 +1000:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in message 
 news:8qfek2-la7.ln1 lnews.kuehne.cn...

 Matthew schrieb am Sun, 1 May 2005 18:00:06 +1000:

 "Thomas Kuehne" <thomas-dloop kuehne.thisisspam.cn> wrote in 
 message
 news:peeek2-la7.ln1 lnews.kuehne.cn...

 Matthew schrieb am Sun, 1 May 2005 16:36:05 +1000:

 Is there a mechanism for making things private to the current
 class
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to
 prevent the Record class from having write access to any of the
 members of the Field class, in order to ensure there are no
 erroneous breaking of the immutable characteristics of the 
 Field
 type. But because they are - have to be - defined in the same
 package, anything can scribble on anything else. Horrid.


 What is the problem with using 2+ modules in the same package?


 I can't say, as I don't know what that means. Can you elucidate?


 Modules b and c are part of the same package a:

 module a.b;
 module a.c;

 Now you can use the access attribute "package" for more 
 fine-grained control.


 I'm think I'm getting hints at what you mean, but need more info. 
 Can you show with a bit more code? 


Congratulations, seems you have unearthed a bug with "package" and
"protected". I'm not yet sure when/why but sometimes the access
restrictions are ignored.

- ---------
module a.b;

class Foo{
	private int a;
	package int b; 
	protected int c;
	public int d;
}

- ---------
module a.c;
import a.b;

void bar(Foo f){
	f.a=0; // illegal
	f.b=1; // OK
	f.c=2; // OK
	f.d=3; // OK
}

- ---------
module some.third.party;
import a.b;

class Bar : Foo{
	void check(Foo f){
		a=0; // illegal
		b=1; // illegal /* BUG */
		c=2; // OK
		d=3; // OK
	}
} 

- ---------

module another.third.party;
import a.b;

void check(Foo f){
	f.a=0; // illegal
	f.b=1; // illegal /* BUG */
	f.c=2; // illegal /* BUG */
	f.d=3; // legal
}

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCdbV/3w+/yD4P9tIRAsl8AKCgQA99zJlbUPT3jQs/ctrlJnPPggCdF+D4
GFNg7CWEnMn/QANcOqdk3AQ=
=mj5T
-----END PGP SIGNATURE-----
May 01 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d51vdc$23uo$1 digitaldaemon.com...

 Is there a mechanism for making things private to the current class only, 
 and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to prevent the 
 Record class from having write access to any of the members of the Field 
 class, in order to ensure there are no erroneous breaking of the immutable 
 characteristics of the Field type. But because they are - have to be - 
 defined in the same package, anything can scribble on anything else. 
 Horrid.


  ^^^^^^^
I assume you mean "module"?


 How about a

    "private private"

 qualifier. (Of course, I don't think anything should be able to see inside 
 anything else by default, but that's not going to change, so this is the 
 next best thing.)

 Thoughts?


Everything in the same module are "friends" to each other. If one has two 
classes that aren't friends put them in different modules.
May 01 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d52rrf$2ovp$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d51vdc$23uo$1 digitaldaemon.com...

 Is there a mechanism for making things private to the current 
 class only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to 
 prevent the Record class from having write access to any of the 
 members of the Field class, in order to ensure there are no 
 erroneous breaking of the immutable characteristics of the Field 
 type. But because they are - have to be - defined in the same 
 package, anything can scribble on anything else. Horrid.


  ^^^^^^^
 I assume you mean "module"?


For package? Maybe I do. I could be massively ignorant on this 
issue.


 How about a

    "private private"

 qualifier. (Of course, I don't think anything should be able to 
 see inside anything else by default, but that's not going to 
 change, so this is the next best thing.)

 Thoughts?


 Everything in the same module are "friends" to each other. If one 
 has two classes that aren't friends put them in different modules.


But are they not then in different 'namespaces'?  How do I refer to 
them in some third-party code?
May 01 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d54a26$qks$2 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
 news:d52rrf$2ovp$1 digitaldaemon.com...

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
 news:d51vdc$23uo$1 digitaldaemon.com...

 Is there a mechanism for making things private to the current class 
 only, and _not_ the package.

 For example, in the expansion to Open-RJ we need to be able to prevent 
 the Record class from having write access to any of the members of the 
 Field class, in order to ensure there are no erroneous breaking of the 
 immutable characteristics of the Field type. But because they are - have 
 to be - defined in the same package, anything can scribble on anything 
 else. Horrid.


  ^^^^^^^
 I assume you mean "module"?


 For package? Maybe I do. I could be massively ignorant on this issue.



equivalent of file-protection.


 How about a

    "private private"

 qualifier. (Of course, I don't think anything should be able to see 
 inside anything else by default, but that's not going to change, so this 
 is the next best thing.)

 Thoughts?


 Everything in the same module are "friends" to each other. If one has two 
 classes that aren't friends put them in different modules.


 But are they not then in different 'namespaces'?  How do I refer to them 
 in some third-party code?


That's true - they would be in different namespaces. One can alias together 
but that would be annoying to do for small internal data structures. On the 
other hand small internal data structures have a low risk of being misused 
by the code in the same file. Personally I'd just keep them in one module. 
One can protect oneself from oneself only so much (IMO).
May 02 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <d51vdc$23uo$1 digitaldaemon.com>, Matthew says...

Is there a mechanism for making things private to the current class 
only, and _not_ the package.


You could use "protected."  Though this obviously means that the data is visible
to a derived class.


For example, in the expansion to Open-RJ we need to be able to 
prevent the Record class from having write access to any of the 
members of the Field class, in order to ensure there are no 
erroneous breaking of the immutable characteristics of the Field 
type. But because they are - have to be - defined in the same 
package, anything can scribble on anything else. Horrid.


I'd like to believe that a module writer won't violate principles he's invented.
But I agree that it would be nice to have an easy way to verify this at
compilation-time.


Sean
May 02 2005