On Mon, 13 Feb 2006 19:17:30 -0800, Andrew Fedoniouk wrote:

>> If you have a class A, how do you make a const instance of it?
> 
> class A
> {
>     int foo() {  return _foo; }
> 
>     package this() {}
>     package ~this(){}
> 
> // data
>     package int _foo;
> }
> 
> Instances of this class are effectively read-only outside of your package and are managed by your package.

Thanks Andrew,
this is almost there for me too. I did some testing and it works for the
most part. The part I can't seem to get working is that modules in the same
package still can't access the 'package' members.

Consider my test...

----- m1.d ----
import m2;
void Bar()
{
    Q q;
    q.Foo();
}

---- m2.d ----
import m1;
struct Q
{
 package void Foo() {}
}
-------------

Now I have these in the same directory and compile with "dmd m1 m2 -c" but get this message "m1.d(5): struct m2.Q member Foo is not accessible".

However, if I make this change to m2.d ...

---- m2.d ----
import m1;
package struct Q
{
 void Foo() {}
}

------------

now it compiles. But my understanding is that the 'package' modifier only applies if it is against a method name and not a class declaration.


BTW, the 'package' modifier still let's me do nasty things if I really had to ...

   Q q;
   real *b;
   *(b = cast(real *)&q) = 3.14;

This compiles even if 'package' or 'private' has been specified, thus allowing very low-level updating.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
14/02/2006 3:13:19 PM

"Sean Kelly" <sean@f4.ca> wrote in message news:dsr5rm$82h$1@digitaldaemon.com...
> Basically, because Walter isn't entirely happy with any existing implementations (C++ being one such example) and is hoping a better solution comes to light.  Feelings on this issue are mixed, because while most people seem to agree that the C++ method isn't ideal, many still want some checking in place.  This issue competes with the bit/bool issue in being the most debated topic on this forum ;-)

LOL, that's a good summary of the situation.

"Derek Parnell" <derek@psych.ward> wrote in message news:oulocmdyp9w8.8tq0o500xmxx$.dlg@40tude.net...
> BTW, the 'package' modifier still let's me do nasty things if I really had to ...
>
>   Q q;
>   real *b;
>   *(b = cast(real *)&q) = 3.14;
>
> This compiles even if 'package' or 'private' has been specified, thus allowing very low-level updating.

With casting and pointers, you'll *always* be able to subvert both the type system and any const semantics (unless const data is protected by the hardware). The interesting question is whether such deliberate subversion invokes defined or undefined behavior.

On Mon, 13 Feb 2006 21:54:37 -0800, Walter Bright wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:oulocmdyp9w8.8tq0o500xmxx$.dlg@40tude.net...
>> BTW, the 'package' modifier still let's me do nasty things if I really had to ...
>>
>>   Q q;
>>   real *b;
>>   *(b = cast(real *)&q) = 3.14;
>>
>> This compiles even if 'package' or 'private' has been specified, thus allowing very low-level updating.
> 
> With casting and pointers, you'll *always* be able to subvert both the type system and any const semantics (unless const data is protected by the hardware). The interesting question is whether such deliberate subversion invokes defined or undefined behavior.

I guess I didn't make it clear but I think that its a *good* thing that D allows this close-to-the-metal coding. There are going to be times when such anti-social coding is justified.

So is the 'package' issue I also talked about a bug or expected behaviour?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
14/02/2006 5:49:02 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:1tpldiq9zop22.1ck8djgnrm2j2$.dlg@40tude.net...
> I guess I didn't make it clear but I think that its a *good* thing that D allows this close-to-the-metal coding. There are going to be times when such anti-social coding is justified.

I agree, which fits in with D being a systems level language.

> So is the 'package' issue I also talked about a bug or expected behaviour?

I'll have to study it, as it wasn't immediately obvious.

In article <oulocmdyp9w8.8tq0o500xmxx$.dlg@40tude.net>, Derek Parnell says...
>
>this is almost there for me too. I did some testing and it works for the most part. The part I can't seem to get working is that modules in the same package still can't access the 'package' members.
>
>Consider my test...
>
>----- m1.d ----
>import m2;
>void Bar()
>{
>    Q q;
>    q.Foo();
>}
>
>---- m2.d ----
>import m1;
>struct Q
>{
> package void Foo() {}
>}
>-------------
>
>Now I have these in the same directory and compile with "dmd m1 m2 -c" but get this message "m1.d(5): struct m2.Q member Foo is not accessible".

If you add a 'package specifier' to each module declaration then it will work, which is consistent with the docs:

module test.m1;
import m2;
void Bar()
{
Q q;
q.Foo();
}
;---
module test.m2;
import m1;
struct Q
{
package void Foo() {}
}

>
>However, if I make this change to m2.d ...
>
>---- m2.d ----
>import m1;
>package struct Q
>{
> void Foo() {}
>}
>
>------------
>
>now it compiles. But my understanding is that the 'package' modifier only applies if it is against a method name and not a class declaration.
>

'package' is ignored here (so is final). I think the only attribute that applies to an aggregate like that is 'final' for classes. That would explain the issue below too.

This has caused quite a bit of confusion in the past - I wish the compiler would flag things like 'private class' because they are ignored and can be misleading.

>BTW, the 'package' modifier still let's me do nasty things if I really had to ...
>
>   Q q;
>   real *b;
>   *(b = cast(real *)&q) = 3.14;
>
>This compiles even if 'package' or 'private' has been specified, thus allowing very low-level updating.
>
>Derek
>(skype: derek.j.parnell)
>Melbourne, Australia
>"Down with mediocracy!"
>14/02/2006 3:13:19 PM

In article <dssvnu$1u8a$1@digitaldaemon.com>, Dave says...
>
>'package' is ignored here (so is final). I think the only attribute that applies to an aggregate like that is 'final' for classes. That would explain the issue

That should read "so is private".

>This has caused quite a bit of confusion in the past - I wish the compiler would flag things like 'private class' because they are ignored and can be misleading.
>

Derek Parnell wrote:
> ------------
> 
> now it compiles. But my understanding is that the 'package' modifier only
> applies if it is against a method name and not a class declaration.
> 
> 
> BTW, the 'package' modifier still let's me do nasty things if I really had
> to ...
> 
>    Q q;
>    real *b;
>    *(b = cast(real *)&q) = 3.14;
> 
> This compiles even if 'package' or 'private' has been specified, thus
> allowing very low-level updating.
> 

Not methods, but members. That is: methods and fields, but not inner declarations. I don't find this behavior desirable, I think protection attributes should work orthogonally to all entities in declaration blocks/scopes.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."