Jarrett Billingsley wrote:

[...]
>         B b = new B;
>         b. x = 8;  // OK
[...]

It is not OK, that this is okay in any case.
At least it is inconsistent, that the assignment

  (cast(A) b).x= 8; // not OK

is not allowed.

-manfred

[X-posted to D.bugs, F'up staying in D]

"Derek Parnell" <derek@psych.ward> wrote in message news:1ql9ydrigronc.1jzq1rh9e2ry0$.dlg@40tude.net...
> In the grand scheme of all things D, is getting the specification
> documented correctly more or less important than getting the
> implementation
> (a.k.a DMD) right?

Right.

> My POV is that the specs should be settled prior to finalizing the implementation.

Right - and for the protected case, it should work like the C++ model.

Walter Bright wrote:
>> My POV is that the specs should be settled prior to finalizing the implementation.
> 
> Right - and for the protected case, it should work like the C++ model.

I've got a question. (if I may :) )

From specs:
"The class invariant is a contract saying that the asserts must hold true.
The invariant is checked when a class constructor completes, at the start
of the class destructor, before a public or exported member is run, and
after a public or exported function finishes."

D implements C++'s model of protection. That is, the following is legal:

class B {
        invariant {
                   assert(x < 3);
        }

        private:
                int x;
        public:
                void bla(B b) {
                        b.x = 4;  // we can operate on private members
                                  // of some totally other instance
                }
};

The point is, invariants are to ensure instantion is never "broken". But using fact, that one object can operate internaly on other because they are from same class can lead to situation that one instantion will "break" other and that fact will go undetected (no public member was called). The fact of "broken instantion" will problably be detected in some other place but this can be a) confusing b) happens in some critical section.

Do you think this is a kind of issue?

"Dawid Ciezarkiewicz" <dawid.ciezarkiewicz@gmail.com> wrote in message news:do9fbb$1hqq$1@digitaldaemon.com...
> Each instance of class is same as other
> instances. So it can operate on them because it know how not to hurt them.

Yes!  That's it.  A descendant class knows about its parent class, so it should be able to mess with protected members of parent class references because it knows what to do.

Dawid Ciężarkiewicz wrote:
> Walter Bright wrote:
> 
>>>My POV is that the specs should be settled prior to finalizing the
>>>implementation.
>>
>>Right - and for the protected case, it should work like the C++ model.
> 
> 
> I've got a question. (if I may :) )
> 
> From specs:
> "The class invariant is a contract saying that the asserts must hold true.
> The invariant is checked when a class constructor completes, at the start
> of the class destructor, before a public or exported member is run, and
> after a public or exported function finishes."
> 
> D implements C++'s model of protection. That is, the following is legal:
> 
> class B {
>         invariant {
>                    assert(x < 3);
>         }
>                            private:
>                 int x;
>         public:
>                 void bla(B b) {
>                         b.x = 4;  // we can operate on private members
>                                   // of some totally other instance
>                 }
> };
> 
> The point is, invariants are to ensure instantion is never "broken". But
> using fact, that one object can operate internaly on other because they are
> from same class can lead to situation that one instantion will "break"
> other and that fact will go undetected (no public member was called). The
> fact of "broken instantion" will problably be detected in some other place
> but this can be a) confusing b) happens in some critical section.
> 
> Do you think this is a kind of issue?

Hum, very good point. Seems to me that if we can't access protected members of other same-class instances, we shouldn't also be able to access private members of other same-class instances. (also because of consistency, not just because of the invariant issue you mentioned)


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

Bruno Medeiros wrote:

> Dawid Ciężarkiewicz wrote:
>> Walter Bright wrote:
>> 
>>>>My POV is that the specs should be settled prior to finalizing the implementation.
>>>
>>>Right - and for the protected case, it should work like the C++ model.
>> 
>> 
>> I've got a question. (if I may :) )
>> 
>> From specs:
>> "The class invariant is a contract saying that the asserts must hold
>> true. The invariant is checked when a class constructor completes, at the
>> start of the class destructor, before a public or exported member is run,
>> and after a public or exported function finishes."
>> 
>> D implements C++'s model of protection. That is, the following is legal:
>> 
>> class B {
>>         invariant {
>>                    assert(x < 3);
>>         }
>> 
>>         private:
>>                 int x;
>>         public:
>>                 void bla(B b) {
>>                         b.x = 4;  // we can operate on private members
>>                                   // of some totally other instance
>>                 }
>> };
>> 
>> The point is, invariants are to ensure instantion is never "broken". But using fact, that one object can operate internaly on other because they are from same class can lead to situation that one instantion will "break" other and that fact will go undetected (no public member was called). The fact of "broken instantion" will problably be detected in some other place but this can be a) confusing b) happens in some critical section.
>> 
>> Do you think this is a kind of issue?
> 
> Hum, very good point. Seems to me that if we can't access protected members of other same-class instances, we shouldn't also be able to access private members of other same-class instances. (also because of consistency, not just because of the invariant issue you mentioned)

I hope this issue will get attention and will be discussed further. I can easily imagine situations when class will need methods that other instances could operate on but shouldn't be available to public. Such methods should be protected by invariant but not be public. Idealy there would be one more keyword ("public", "protected", "private" and ... "multiinstance" maybe) that will do the deal. In such model class could operate only on "this" pointer AND on public and multinstance methods of pointers from same (or parent) class. But this would be big change and this is only free idea.

On Wed, 21 Dec 2005 16:55:35 +0000, Bruno Medeiros wrote:


[snip]

> Seems to me that if we can't access protected members of other same-class instances, we shouldn't also be able to access private members of other same-class instances. (also because of consistency, not just because of the invariant issue you mentioned)

Is there need to consider read and write accesses differently? For it may be okay to have read access to parent class data but not write access.

-- 
Derek Parnell
Melbourne, Australia
22/12/2005 7:51:48 AM

Derek Parnell wrote:

[...]
> Is there need to consider read and write accesses differently? For it may be okay to have read access to parent class data but not write access.

Yes. Because as already stated, write accesses may destroy an invariant of that instantiation.

It is a fiction to believe that all invariants of all instances are the same, because the invariant more or less formally defined for a class may be the minimal invariant shared by all instances.

And the specs do not guarantee optimizing out a definition of a class whose sole purpose is to sharpen the invariant of its super class.

-manfred

Walter Bright wrote:

[...]
>> My POV is that the specs should be settled prior to finalizing the implementation.
> 
> Right - and for the protected case, it should work like the C++ model.

But C++ does not have a model for `protected' in conjunction with `package' or `export'.

In the D-specs the protection attribute `protected' is even left out from the possibilities of protection for the super class and the interfaces.

-manfred