Regan Heath wrote:
[...]
> It "weakens" in the sense that it lessens the protection that protected  gives.
[...]

Isn't the protection `protected' gives already too low?

According to the specs it is the duty of every class to defend its `invariant' for every instantiation.

This defending cannot be done in general, if  other entities have write access to members of the class without using a function of the class.

Therefore all write accesses to members of classes must be forbidden or the definition of what an `invariant' is, must be dropped.

-manfred

I agree, this is unavoidable.

In article <Xns9731EECD4CC86svv1999hotmailcom@63.105.9.61>, Manfred Nowak says...
>
>Regan Heath wrote:
>[...]
>> It "weakens" in the sense that it lessens the protection that protected  gives.
>[...]
>
>Isn't the protection `protected' gives already too low?
>
>According to the specs it is the duty of every class to defend its `invariant' for every instantiation.
>
>This defending cannot be done in general, if  other entities have write access to members of the class without using a function of the class.
>
>Therefore all write accesses to members of classes must be forbidden or the definition of what an `invariant' is, must be dropped.



Tom

In article <do77p6$1le0$1@digitaldaemon.com>, Chris Sauls says...
>
>Ant wrote:
>> Actually this is rigth.
>> You don't have access to the protected members of an object you own.
>> 
>> b.x is visible on b because B extendes A.
>> a.x is NOT visible because x is protected on A.
>
>Maybe I'm missing something, but I've always understood the typical protection attributes
>to mean:
>public = anybody can see it
>private = only this class/object can see it
>protected = only this class/object *and its descendants* can see it
>
>So shouldn't a child class be able to see its parent's protected members?  That's supposed to be the whole idea.  If I wanted it hidden completely, I'd use private, yes?  Or do I misunderstand his issue?
>
>-- Chris Sauls

You misunderstood.

in this case 'a' is a different object, 'a' it's not the "this" object. beeing a different object the protected access modifier doesn't allow you to access the element.

"That's supposed to be the whole idea." ;)

(java makes protected elements visible through the entire package - or
something like don't remember clearly now.
java also has the "package" access - that's the default access there is no
keyword for it)

anyway when I first read the original post I thought "Walter screw it again"
but no, this time he is right.
Other times you are wrong, Walter...

Ant

Chris Sauls wrote:

[...]
> Maybe I'm missing something, but I've always understood the
> typical protection attributes to mean:
> public = anybody can see it
> private = only this class/object can see it
> protected = only this class/object *and its descendants* can see
> it
[...]

From the specs you are right, because they state, that every descendant _class_ can see the protected members of its father _class_.

But this seems to be nonsense, because in fact only instances of classes can control something at runtime and if an instance of a class can conrol the members of any other instance of this class, the instance of the class with members controlled would loose its autonomy, especially its role to shield its data.

Therefore the specs should state, that every "instance of a descendant class" can see the protected members of the "instance of its father class" only.

-manfred

On Tue, 20 Dec 2005 05:13:49 +0000 (UTC), Manfred Nowak wrote:


> From the specs you are right, because they state, ...

> But this seems to be nonsense, because in fact ...

> Therefore the specs should state, that ...

Walter,
I don't want to sound impertinent, so please take this in the friendly
manner it was meant.

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?

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

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
20/12/2005 4:28:57 PM

Tom wrote:

> I agree, this is unavoidable.
[...]

Thanks for your affirmative answer, but my conclusion seems to be at least partly wrong.


If a class declares a member to be `protected' although it is a vital member of its invariant, then the definition of the class is faulty.

Maybe the language should change the names of its protection attributes to represent the impact of the protection attribute instead of the abstract description of the effect:

`invariable' instead of `private'
`inheretable' instead of `protected'
`unprotected' instad of `public'


According to the absence of protectection of invariants in modules, this seems to propose a maintenance disaster, because it is based on easying the coding and not the maintenenance.

Every maintainer wants to be sure to not destroy accidentically an invariant of a class. But how can a maintainer do that without knowing the details of the implementaions of every invariant of the module she/he is working on, in case of the current specs, where every coder is allowed to distribute the components defending the invariants all over a module.

On the other hand I do not see, how to make those components easily locatable.

-manfred

Ant wrote:
> In article <do77p6$1le0$1@digitaldaemon.com>, Chris Sauls says...
> 
>>Ant wrote:
>>
>>>Actually this is rigth.
>>>You don't have access to the protected members of an object you own.
>>>
>>>b.x is visible on b because B extendes A.
>>>a.x is NOT visible because x is protected on A.
>>
>>Maybe I'm missing something, but I've always understood the typical protection attributes to mean:
>>public = anybody can see it
>>private = only this class/object can see it
>>protected = only this class/object *and its descendants* can see it
>>
>>So shouldn't a child class be able to see its parent's protected members?  That's supposed to be the whole idea.  If I wanted it hidden completely, I'd use private, yes?  Or do I misunderstand his issue?
>>
>>-- Chris Sauls
> 
> 
> You misunderstood.
> 
> in this case 'a' is a different object, 'a' it's not the "this" object.
> beeing a different object the protected access modifier doesn't allow you to access the element.

But 'b' is a *descendant of* 'a' (aka, subclass) so 'protected' members are supposed to be visible!  It sounds like you really want 'private' behavior here??

-- Chris Sauls

Manfred Nowak wrote:
> Chris Sauls wrote:
> 
> [...]
>> Maybe I'm missing something, but I've always understood the
>> typical protection attributes to mean:
>> public = anybody can see it
>> private = only this class/object can see it
>> protected = only this class/object *and its descendants* can see
>> it
> [...]
> 
> From the specs you are right, because they state, that every descendant _class_ can see the protected members of its father _class_.
> 
> But this seems to be nonsense, because in fact only instances of classes can control something at runtime and if an instance of a class can conrol the members of any other instance of this class, the instance of the class with members controlled would loose its autonomy, especially its role to shield its data.

There are two kind of protection. Class- and object- protection. In C++ there is a class-protection implemented and I used this fact from time to time. Current D spec seems to use class-protection but implementation behaves like object-protection. I do not wish to advocate, but class-protection isn't nonsense. Each instance of class is same as other instances. So it can operate on them because it know how not to hurt them. Actualy I think in D object-protection should be used because of invariants and other well designed things in D. The specification is just wrong, happens.

Manfred Nowak wrote:
> Chris Sauls wrote:
> 
> [...]
> 
>>Maybe I'm missing something, but I've always understood the
>>typical protection attributes to mean:
>>public = anybody can see it
>>private = only this class/object can see it
>>protected = only this class/object *and its descendants* can see
>>it 
> 
> [...]
> 
> From the specs you are right, because they state, that every descendant _class_ can see the protected members of its father _class_.
> 
> But this seems to be nonsense, because in fact only instances of classes can control something at runtime and if an instance of a class can conrol the members of any other instance of this class, the instance of the class with members controlled would loose its autonomy, especially its role to shield its data.
> 
> Therefore the specs should state, that every "instance of a descendant class" can see the protected members of the "instance of its father class" only.

But isn't the "instance of its father class" the same as "instance of a descendant class". Of course there's some polymorphism between them, but I think these refer to the same object.

Should it be something like "the instance of a descendant class recursively inherits the protected members of the father class, but is not allowed to access protected members of other classes unless they are 'friends' (in the same module)".

Chris Sauls wrote:
> Ant wrote:
 >
> But 'b' is a *descendant of* 'a' (aka, subclass) so 'protected' members are supposed to be visible!  It sounds like you really want 'private' behavior here??

No. The *class* B is a descendant of the *class* A, but the *instance* b has no relationship with the *instance* of a. b should *not* be able to access the protected members of any instance of A, only that of its super instance (i.e. that which is part of its own memory space). It will have access to the protected members of any instance of B. And if you cast it to an A it will then have access to the protected members of any instance of A - because then it is not a B anymore but an A.