Encapsulation vs Extensibility

Mark Nicholls wrote:

> S Perryman wrote:

>>Mark Nicholls wrote:

>>>I'm not saying you're wrong just I don't understand....to me private
>>>members are invisible to types.

>>Inheritance is of the *whole* type, not just the parts made available
>>to the *users* . If the REP of X changes, Y may have to rebuild. In prog
>>langs with inferior build strategy (C++ etc) , rebuild is definite. So
>>the use of 'private' has not helped here.

> inheritance is an implementation mapping defined on types....we should
> agree here....it is defined on the whole type...yes.


> "http://web.mit.edu/6.170/www/supplemental-info/abstraction-functions-and-rep-invariants.html"

> helps alot.....they are what I would call interpretations of a type in
> another type.....

> now I just don't agree...! which is a step forward.

> Y-|>X
>
> If REP of X changes in such a way that the type of X
> changes....especially if this new X' is not substitutable for the
> original X, then effectively it has broken it's contract....either we
> have to 'fix' X' to obey it's original contract, or we have to enhance
> Y (i.e. create Y') to inherit X' in such a way that.

Changes to X.REP is a CM issue, not a semantic issue (contracts) .
Y is coupled to that change regardless of whether the semantics of X
change.


> from an engineering perspectve the less complex the exposed type, the
> less likely REP is going to change due to incidental fixes/changes to
> X...the less likely we either have
> a) bugs
> b) have rippling effects down the inheritance tree.

> the second point is an 'opinion'...the first is an comment on the
> 'science'....(possible a wrong one...or one with different premises to
> your comments).

See below.


>>OOSC2 (chapter 6, then page 373)

>>http://web.mit.edu/6.170/www/supplem...nvariants.html

>>And then you will understand why making all properties of X available to
>>implementors of Y is not a problem for developers of ADTs.

> see above....maybe I missed the point.

You have indeed.

1. Making X.REP private conflicts with the open-closed principle.

If Y implementors are refused the right to manipulate X.REP in a manner
that best-serves their purpose, X is less usable.


2. The perennial claim that making X.REP private somehow ensures Y
implementors cannot do something stupid is killed by ADT theory.

ADT developers provide *REP invariants* .
REP invariants define the conditions under which X.REP actually
constitutes an instance of ADT X. They are also additional correctness
enforcers (ADTs may already have ABS invariants - which are REP-
independent) .

Y implementors can play with X.REP forever and a day, but defects will be
found by the REP invariant (if not also by the ABS invariant) .


Regards,
Steven Perryman

"Mark Nicholls" <Nicholls.Mark{}mtvne.com> wrote:
> Daniel T. wrote:
> > "Mark Nicholls" <Nicholls.Mark{}mtvne.com> wrote:
> > > Daniel T. wrote:

> > > > I suggest making a field private when there is some invariant
> > > > relationship between it and some other field that the class also
> > > > contains. That way no outside code can break the invariant. (If
> > > > the field in question has no such relationship with any other
> > > > fields in the class, maybe it's in the wrong class.)
> > >
> > > OK if it's private rather than public... no client code, or
> > > subclasses (by which I mean implementation inheritance) can break
> > > the invariant. if it's private rather than protected... no subclasses
> > > can break the invariant...
> > >
> > > seems to be rather tied up with subclassing.
> >
> > Not at all. It's tied up with who is supposed to maintain the invariant.
> > If the field is either public or protected, then the class can't
> > guarantee the invariant and must trust others to do so. Why trust others
> > to do your job? When it comes to the invariant, there is no difference
> > between public and protected.
>
> (comment on the 'science')
> OK... 2 points... yes... if the field is public or protecred the class
> can't guarentee it is another way of saying if the class has to
> guarentee an invariant then it cannot be protected or public...
>
> (opinion)
> now in the 'real' world it's often not clear whether the code is
> dependent on an invariant or not... software is complex... so in
> general if in doubt make it private... that way you'll have less bugs
> due to accidentally exposing invariants and having them accidentally
> broken...

When in doubt, I agree, make it private. But let's make sure we know
what we are talking about:

The values of the members and the objects referred to by members
are collectively called the state of the object (or simply, its
value). A major concern of a class design is to get an object into
a well-defined state (initialization/construction), to maintain a
well-defined state as operations are performed, and finally to
destroy the object gracefully. The property that makes the state
of an object well-defined is called its invariant. [Stroustrup]

I have to ask, if you don't know what states are well defined for
objects of your class, how are you going to make code with fewer bugs?

> yes the class is responsible for guarenteeing it's contract... it's
> much much easier to write code that guarentees that contract if
> there is as little opporunity from external clients for breaking it.
>
> basically it is unrealistic to premise software production on
> proposition that all implementations are correct,

Your basic argument seems to be that the implementer either doesn't or
may not know what he is implementing. Because of that lack of knowledge
he may expose methods/fields that shouldn't have been exposed. I agree
with your stance *if* the implementer doesn't know what he is doing.

However, if one assumes, in the general case, that no implementation is
correct then reuse becomes impossible. When reusing a class (through
delegation or inheritance,) we have every right to assume that it was
implemented correctly, and that if it wasn't it will be fixed. "Not
implemented correctly" means that I fulfilled my end of the contract,
but the class I'm using didn't fulfill its end. It is completely
reasonable for me to assume that methods I call will ensure the
invariant and any post-condition they may have (assuming I ensured the
pre-condition.)

> and the cost of correct implementation is invariant to complexity of
> contract and/or signature.

Of course correct implementation and complexity of contract are related,
because both are contingent on the complexity of the invariant. I don't
think my stance is in any way based on the premise you cite.

However, I will say that my stance is based on the premise that the
invariant is known. Something that you seem to think is an unreasonable
premise.

> I agree with your analysis, but not the engineering opinion you
> conclude.

It could be that we aren't really talking about the same thing. For
example, I notice you have mentioned sub-classing several times whereas
I think it is rarely the case that a full implementation can, or should,
be sub-classed.

S Perryman wrote:
> Mark Nicholls wrote:
>
> > S Perryman wrote:
>
> >>Mark Nicholls wrote:
>
> >>>I'm not saying you're wrong just I don't understand....to me private
> >>>members are invisible to types.
>
> >>Inheritance is of the *whole* type, not just the parts made available
> >>to the *users* . If the REP of X changes, Y may have to rebuild. In prog
> >>langs with inferior build strategy (C++ etc) , rebuild is definite. So
> >>the use of 'private' has not helped here.
>
> > inheritance is an implementation mapping defined on types....we should
> > agree here....it is defined on the whole type...yes.
>
>
> > "http://web.mit.edu/6.170/www/supplemental-info/abstraction-functions-and-rep-invariants.html"
>
> > helps alot.....they are what I would call interpretations of a type in
> > another type.....
>
> > now I just don't agree...! which is a step forward.
>
> > Y-|>X
> >
> > If REP of X changes in such a way that the type of X
> > changes....especially if this new X' is not substitutable for the
> > original X, then effectively it has broken it's contract....either we
> > have to 'fix' X' to obey it's original contract, or we have to enhance
> > Y (i.e. create Y') to inherit X' in such a way that.
>
> Changes to X.REP is a CM issue,

CM?

> not a semantic issue (contracts) .

contracts to me are not semantic....!.....they are syntactic constructs
that are preserved over different semantic implementations......lets
not go there, it probably doesn't matter and I suspect it's just a
labelling of words issue.

> Y is coupled to that change regardless of whether the semantics of X
> change.

Y is coupled to the contracts of X....no more than that, it promises to
satisfy it's contracts given that X satisfies it's.

>
>
> > from an engineering perspectve the less complex the exposed type, the
> > less likely REP is going to change due to incidental fixes/changes to
> > X...the less likely we either have
> > a) bugs
> > b) have rippling effects down the inheritance tree.
>
> > the second point is an 'opinion'...the first is an comment on the
> > 'science'....(possible a wrong one...or one with different premises to
> > your comments).
>
> See below.
>
>
> >>OOSC2 (chapter 6, then page 373)
>
> >>http://web.mit.edu/6.170/www/supplem...nvariants.html
>
> >>And then you will understand why making all properties of X available to
> >>implementors of Y is not a problem for developers of ADTs.
>
> > see above....maybe I missed the point.
>
> You have indeed.
>
> 1. Making X.REP private conflicts with the open-closed principle.

The example of Line given in the link, has a "Representation Invariant"
that constrains 4 private fields...
Is this the REP you are talking about....I may be confused.

REP is the fields that 'represent' the class?

>
> If Y implementors are refused the right to manipulate X.REP in a manner
> that best-serves their purpose, X is less usable.

OK....it is less usable.....then making them non private becomes an
opinion of the relative merits of 'usability' against the cost
(whatever that is) of keeping it private.....so I need to establish a
cost....the rest after that is 'opinion' on that trade off.

>
>
> 2. The perennial claim that making X.REP private somehow ensures Y
> implementors cannot do something stupid is killed by ADT theory.

the claim that Y implementors can't do something stupid is self evident
(to me).
your claim seems to be that if REP is not private Y implementors can't
do somehting stupid.

Is this what you are claiming?

>
> ADT developers provide *REP invariants* .
> REP invariants define the conditions under which X.REP actually
> constitutes an instance of ADT X.

OK...does the code not compile if the client tries to invalidate the
condition?

To me there is a Type TX.....the class X claims to implement this type
and has constraints (premises) defined on it in order to prove that X
does indeed implement the type TX.

The class X should to be independendly deployable and 'correct' in all
deployments, thus run time checks are inadequate....thus the premise
has to be private...if it is not private then I cannot verify at
compile time correctness in an arbritrary deployment.

> They are also additional correctness
> enforcers (ADTs may already have ABS invariants - which are REP-
> independent) .

I saw the abstraction function...that is fine.....the ABS invariant
would constrain the this function?...i.e. it would be a condition
between domain and codomain of the abstraction function?

rather like claiming

f(a.x) = a.f(x) ?

>
> Y implementors can play with X.REP forever and a day, but defects will be
> found by the REP invariant (if not also by the ABS invariant) .
>

They will be 'found'?

how will the invariants tell me they have 'found' the defect?

Daniel T. wrote:
> "Mark Nicholls" <Nicholls.Mark{}mtvne.com> wrote:
> > Daniel T. wrote:
> > > "Mark Nicholls" <Nicholls.Mark{}mtvne.com> wrote:
> > > > Daniel T. wrote:
>
> > > > > I suggest making a field private when there is some invariant
> > > > > relationship between it and some other field that the class also
> > > > > contains. That way no outside code can break the invariant. (If
> > > > > the field in question has no such relationship with any other
> > > > > fields in the class, maybe it's in the wrong class.)
> > > >
> > > > OK if it's private rather than public... no client code, or
> > > > subclasses (by which I mean implementation inheritance) can break
> > > > the invariant. if it's private rather than protected... no subclasses
> > > > can break the invariant...
> > > >
> > > > seems to be rather tied up with subclassing.
> > >
> > > Not at all. It's tied up with who is supposed to maintain the invariant.
> > > If the field is either public or protected, then the class can't
> > > guarantee the invariant and must trust others to do so. Why trust others
> > > to do your job? When it comes to the invariant, there is no difference
> > > between public and protected.
> >
> > (comment on the 'science')
> > OK... 2 points... yes... if the field is public or protecred the class
> > can't guarentee it is another way of saying if the class has to
> > guarentee an invariant then it cannot be protected or public...
> >
> > (opinion)
> > now in the 'real' world it's often not clear whether the code is
> > dependent on an invariant or not... software is complex... so in
> > general if in doubt make it private... that way you'll have less bugs
> > due to accidentally exposing invariants and having them accidentally
> > broken...
>
> When in doubt, I agree, make it private. But let's make sure we know
> what we are talking about:
>
> The values of the members and the objects referred to by members
> are collectively called the state of the object (or simply, its
> value). A major concern of a class design is to get an object into
> a well-defined state (initialization/construction), to maintain a
> well-defined state as operations are performed, and finally to
> destroy the object gracefully. The property that makes the state
> of an object well-defined is called its invariant. [Stroustrup]

OK....it's basically about defining consistent entries in a tuple.

>
> I have to ask, if you don't know what states are well defined for
> objects of your class, how are you going to make code with fewer bugs?

? I don't understand....as the author of the code, I do know the states
that are well defined....as the client of the class, then I shouldn't
need to know anything about the state of the class, more than is
promised in it's public contract.

>
> > yes the class is responsible for guarenteeing it's contract... it's
> > much much easier to write code that guarentees that contract if
> > there is as little opporunity from external clients for breaking it.
> >
> > basically it is unrealistic to premise software production on
> > proposition that all implementations are correct,
>
> Your basic argument seems to be that the implementer either doesn't or
> may not know what he is implementing. Because of that lack of knowledge
> he may expose methods/fields that shouldn't have been exposed. I agree
> with your stance *if* the implementer doesn't know what he is doing.

I think we're talking about different things....I'm saying internal
'state' is internal, there may be bits that I can provably make public
and the code still satisfy it's contract, but I may not have tools or
the ability to know for sure.

>
> However, if one assumes, in the general case, that no implementation is
> correct then reuse becomes impossible.

correct!

that is the difference between talking about the 'science' of computer
programs, and the act of engineering it......all metal suffers from
metal fatigue, and is guarenteed to fail....does that then mean we
cannot build planes?.....no we just build engineering and operation
practices that mitigate this risk.


> When reusing a class (through
> delegation or inheritance,) we have every right to assume that it was
> implemented correctly, and that if it wasn't it will be fixed. "Not
> implemented correctly" means that I fulfilled my end of the contract,
> but the class I'm using didn't fulfill its end. It is completely
> reasonable for me to assume that methods I call will ensure the
> invariant and any post-condition they may have (assuming I ensured the
> pre-condition.)

I agree....but don't be suprised when someone rings up and says you've
got a bug on line 50.....if you are right then this would *never*
happen, it would be impossible....but it happens *alot*, thus a
practice that seeks to minimise this, even if theoretically in a
perfect world is unnecessary is still valid.

>
> > and the cost of correct implementation is invariant to complexity of
> > contract and/or signature.
>
> Of course correct implementation and complexity of contract are related,
> because both are contingent on the complexity of the invariant. I don't
> think my stance is in any way based on the premise you cite.
>
> However, I will say that my stance is based on the premise that the
> invariant is known. Something that you seem to think is an unreasonable
> premise.

the premise is known to who?

Is the invariant part of the published type?....is it necessary
irrespectve of the implementation to be known?...i.e. can I write a
client that satisfies it's contract without knowing this
information?.....if so, then it seems to me it is unnecessary
coupling.....which (from an engineering perspective) is bad.

>
> > I agree with your analysis, but not the engineering opinion you
> > conclude.
>
> It could be that we aren't really talking about the same thing. For
> example, I notice you have mentioned sub-classing several times whereas
> I think it is rarely the case that a full implementation can, or should,
> be sub-classed.

I suffer from Lahmanism....i.e. I use words that sometimes don't
coincide with general usage.

by subclassing I meant implementation inheritance....it's probably a
misnomer on my part, basically I was trying to explicitly distinguish
it from subtyping.

Mark Nicholls wrote:

> S Perryman wrote:

>>Mark Nicholls wrote:

>>>"http://web.mit.edu/6.170/www/supplemental-info/abstraction-functions-and-rep-invariants.html"

>>>helps alot.....they are what I would call interpretations of a type in
>>>another type.....

>>>now I just don't agree...! which is a step forward.

>>>Y-|>X

>>>If REP of X changes in such a way that the type of X
>>>changes....especially if this new X' is not substitutable for the
>>>original X, then effectively it has broken it's contract....either we
>>>have to 'fix' X' to obey it's original contract, or we have to enhance
>>>Y (i.e. create Y') to inherit X' in such a way that.

>>Changes to X.REP is a CM issue,

> CM?

Configuration management.


>>Y is coupled to that change regardless of whether the semantics of X
>>change.

> Y is coupled to the contracts of X....no more than that, it promises to
> satisfy it's contracts given that X satisfies it's.

No. Y has a CM dependency on X via inheritance.
If the impl of X changes, but the semantics of X do not, Y is probably
going to be rebuilt. If the semantics of X change, Y will have to be
re-built/tested (possibly re-implemented) .

Such as the coupling that inheritance brings.


>>>from an engineering perspectve the less complex the exposed type, the
>>>less likely REP is going to change due to incidental fixes/changes to
>>>X...the less likely we either have
>>>a) bugs
>>>b) have rippling effects down the inheritance tree.

>>>the second point is an 'opinion'...the first is an comment on the
>>>'science'....(possible a wrong one...or one with different premises to
>>>your comments).

>>See below.

SP>http://web.mit.edu/6.170/www/supplem...nvariants.html

SP>And then you will understand why making all properties of X available to
SP>implementors of Y is not a problem for developers of ADTs.

>>>see above....maybe I missed the point.

>>You have indeed.

>>1. Making X.REP private conflicts with the open-closed principle.

> The example of Line given in the link, has a "Representation Invariant"
> that constrains 4 private fields...
> Is this the REP you are talking about.

The four instance variables comprise the REP.
The REP invariant is the constraint you mention.


>>If Y implementors are refused the right to manipulate X.REP in a manner
>>that best-serves their purpose, X is less usable.

> OK....it is less usable.....then making them non private becomes an
> opinion of the relative merits of 'usability' against the cost
> (whatever that is) of keeping it private.....so I need to establish a
> cost....the rest after that is 'opinion' on that trade off.

I am interested to see how you define 'usability' and 'cost' .


>>2. The perennial claim that making X.REP private somehow ensures Y
>> implementors cannot do something stupid is killed by ADT theory.

> the claim that Y implementors can't do something stupid is self evident
> (to me).
> your claim seems to be that if REP is not private Y implementors can't
> do somehting stupid.

> Is this what you are claiming?

I am claiming that the fear of Y implementors doing something stupid is
moot in the presence of REP (and ABS) invariants. If they do not touch
X.REP, the effect is the same as if X.REP was private. If they do touch
X.REP, executing the invariants will determine whether they have been
stupid.

The REP invariant is a contract that *implementors* must obey when playing
with X.REP.


> To me there is a Type TX.....the class X claims to implement this type
> and has constraints (premises) defined on it in order to prove that X
> does indeed implement the type TX.

> The class X should to be independendly deployable and 'correct' in all
> deployments, thus run time checks are inadequate.

In the absence of theorem-proving, runtime checks are all you have.


>...thus the premise
> has to be private...if it is not private then I cannot verify at
> compile time correctness in an arbritrary deployment.

???


>>They are also additional correctness
>>enforcers (ADTs may already have ABS invariants - which are REP-
>>independent) .

> I saw the abstraction function...that is fine.....the ABS invariant
> would constrain the this function?...i.e. it would be a condition
> between domain and codomain of the abstraction function?

The ABS invariant is a property of the abstraction (ie the ADT) .
It is something that is true of the abstraction regardless of the
implementation (representation) .


>>Y implementors can play with X.REP forever and a day, but defects will be
>>found by the REP invariant (if not also by the ABS invariant) .

> They will be 'found'?

> how will the invariants tell me they have 'found' the defect?

The same way all DBC violations are found.
At run-time. With the identity given for the REP invariant that failed.


Regards,
Steven Perryman

S Perryman wrote:
> Mark Nicholls wrote:
>
> > S Perryman wrote:
>
> >>Mark Nicholls wrote:
>
> >>>"http://web.mit.edu/6.170/www/supplemental-info/abstraction-functions-and-rep-invariants.html"
>
> >>>helps alot.....they are what I would call interpretations of a type in
> >>>another type.....
>
> >>>now I just don't agree...! which is a step forward.
>
> >>>Y-|>X
>
> >>>If REP of X changes in such a way that the type of X
> >>>changes....especially if this new X' is not substitutable for the
> >>>original X, then effectively it has broken it's contract....either we
> >>>have to 'fix' X' to obey it's original contract, or we have to enhance
> >>>Y (i.e. create Y') to inherit X' in such a way that.
>
> >>Changes to X.REP is a CM issue,
>
> > CM?
>
> Configuration management.
>

OK

>
> >>Y is coupled to that change regardless of whether the semantics of X
> >>change.
>
> > Y is coupled to the contracts of X....no more than that, it promises to
> > satisfy it's contracts given that X satisfies it's.
>
> No. Y has a CM dependency on X via inheritance.
> If the impl of X changes, but the semantics of X do not, Y is probably
> going to be rebuilt. If the semantics of X change, Y will have to be
> re-built/tested (possibly re-implemented) .

To me this is a detail due to the static implementation of
inheritance.....to me (I believe) implementation inheritance can be
isomorphically mapped into a delegation mechanism....this delegation
mechanism does not require recompilation, thus the notion of
substitutability of base class directly corresponds to the notion of
substitutation of subtype for 'normal' client class scenario's i.e.
Liskov bla bla bla.....

Thus it comes for free.....you change the base class, you are
effectively substituting a type...if that type obeys the original type
contracts then.....bingo...

(aside....I find it bizarre, that your (probably well founded in ADT)
concept of semantics, corresponds to my (I believe well founded in
logic) concept of syntax....but there you go).

>
> Such as the coupling that inheritance brings.
>

And protected allows the coupling, and private prohibits it.

>
> >>>from an engineering perspectve the less complex the exposed type, the
> >>>less likely REP is going to change due to incidental fixes/changes to
> >>>X...the less likely we either have
> >>>a) bugs
> >>>b) have rippling effects down the inheritance tree.
>
> >>>the second point is an 'opinion'...the first is an comment on the
> >>>'science'....(possible a wrong one...or one with different premises to
> >>>your comments).
>
> >>See below.
>
> SP>http://web.mit.edu/6.170/www/supplem...nvariants.html
>
> SP>And then you will understand why making all properties of X available to
> SP>implementors of Y is not a problem for developers of ADTs.
>
> >>>see above....maybe I missed the point.
>
> >>You have indeed.
>
> >>1. Making X.REP private conflicts with the open-closed principle.
>
> > The example of Line given in the link, has a "Representation Invariant"
> > that constrains 4 private fields...
> > Is this the REP you are talking about.
>
> The four instance variables comprise the REP.
> The REP invariant is the constraint you mention.
>
>
> >>If Y implementors are refused the right to manipulate X.REP in a manner
> >>that best-serves their purpose, X is less usable.
>
> > OK....it is less usable.....then making them non private becomes an
> > opinion of the relative merits of 'usability' against the cost
> > (whatever that is) of keeping it private.....so I need to establish a
> > cost....the rest after that is 'opinion' on that trade off.
>
> I am interested to see how you define 'usability' and 'cost' .
>

you said 'usable' not me......I accepted it as an opinion, that I
naively agree with.....by cost I mean negative utility.....which is a
relative concept.....i.e. these notions are not scientific.

>
> >>2. The perennial claim that making X.REP private somehow ensures Y
> >> implementors cannot do something stupid is killed by ADT theory.
>
> > the claim that Y implementors can't do something stupid is self evident
> > (to me).
> > your claim seems to be that if REP is not private Y implementors can't
> > do somehting stupid.
>
> > Is this what you are claiming?
>
> I am claiming that the fear of Y implementors doing something stupid is
> moot in the presence of REP (and ABS) invariants. If they do not touch
> X.REP, the effect is the same as if X.REP was private. If they do touch
> X.REP, executing the invariants will determine whether they have been
> stupid.

The fog is clearing.....a penny has dropped....I may have to think
about it more.....(I don't retract what I said above about the
equivalence to delegations system and substitutability).....

if a invariant is violated, is the objects state rolled back to a
previous valid one?

>
> The REP invariant is a contract that *implementors* must obey when playing
> with X.REP.
>

yes.

>
> > To me there is a Type TX.....the class X claims to implement this type
> > and has constraints (premises) defined on it in order to prove that X
> > does indeed implement the type TX.
>
> > The class X should to be independendly deployable and 'correct' in all
> > deployments, thus run time checks are inadequate.
>
> In the absence of theorem-proving, runtime checks are all you have.

OK, but the absence of them means that we are dependent on humans to be
able to identify the constraints/premises of the software and design
the software to be 'correct'.....private is a defensive policy.....if
it is private then it cannot be violated.....if we had theorem provers
(which there are some about), then the question really comes from the
pro's/con's of wide vs narrow interfaces.

>
>
> >...thus the premise
> > has to be private...if it is not private then I cannot verify at
> > compile time correctness in an arbritrary deployment.
>
> ???

the penny has dropped in this regard.....though I think it's still
going round and round.

>
>
> >>They are also additional correctness
> >>enforcers (ADTs may already have ABS invariants - which are REP-
> >>independent) .
>
> > I saw the abstraction function...that is fine.....the ABS invariant
> > would constrain the this function?...i.e. it would be a condition
> > between domain and codomain of the abstraction function?
>
> The ABS invariant is a property of the abstraction (ie the ADT) .
> It is something that is true of the abstraction regardless of the
> implementation (representation) .

an example?

>
>
> >>Y implementors can play with X.REP forever and a day, but defects will be
> >>found by the REP invariant (if not also by the ABS invariant) .
>
> > They will be 'found'?
>
> > how will the invariants tell me they have 'found' the defect?
>
> The same way all DBC violations are found.
> At run-time. With the identity given for the REP invariant that failed.
>

OK there are theorem provers around...the compiler can tell you....see
spec#.

Mark Nicholls wrote:

> S Perryman wrote:

>>Mark Nicholls wrote:

>>>Y is coupled to the contracts of X....no more than that, it promises to
>>>satisfy it's contracts given that X satisfies it's.

>>No. Y has a CM dependency on X via inheritance.
>>If the impl of X changes, but the semantics of X do not, Y is probably
>>going to be rebuilt. If the semantics of X change, Y will have to be
>>re-built/tested (possibly re-implemented) .

> To me this is a detail due to the static implementation of
> inheritance...

It is a consequence of the dominant forms of implementing inheritance
in prog langs.


to me (I believe) implementation inheritance can be
> isomorphically mapped into a delegation mechanism....this delegation
> mechanism does not require recompilation [...]

You have a demonstration of this (as opposed to belief) ??
If so, take it into another thread.


> (aside....I find it bizarre, that your (probably well founded in ADT)
> concept of semantics, corresponds to my (I believe well founded in
> logic) concept of syntax....but there you go).

Semantics is meaning.
Semantics may be expressed in many different formats (syntax) .


SP>If Y implementors are refused the right to manipulate X.REP in a manner
SP>that best-serves their purpose, X is less usable.

>>>OK....it is less usable.....then making them non private becomes an
>>>opinion of the relative merits of 'usability' against the cost
>>>(whatever that is) of keeping it private.....so I need to establish a
>>>cost....the rest after that is 'opinion' on that trade off.

>>I am interested to see how you define 'usability' and 'cost' .

> you said 'usable' not me......I accepted it as an opinion, that I
> naively agree with.....by cost I mean negative utility.....which is a
> relative concept.....i.e. these notions are not scientific.

Usability of a component C is quite easy to qualitatively measure.

1. As a component user, did C provide what I needed ??
If not, how simple was it to take C and implement the bits (separately or
by extension) to finally provide what I need ??

2. Same for component implementors.


And if C in the context of 1/2 did not satisfy my needs, why not ??

For 2, a big offender is ... making properties of C *private* .
Something that could be done with C if certain properties were made
accessible.


Next, what does 'negative utility' mean ??


> if a invariant is violated, is the objects state rolled back to a
> previous valid one?

No (obviously) . Violation of an invariant is a defect.


>>>The class X should to be independendly deployable and 'correct' in all
>>>deployments, thus run time checks are inadequate.

>>In the absence of theorem-proving, runtime checks are all you have.

> OK, but the absence of them means that we are dependent on humans to be
> able to identify the constraints/premises of the software and design
> the software to be 'correct'.....private is a defensive policy.....if
> it is private then it cannot be violated.....if we had theorem provers
> (which there are some about), then the question really comes from the
> pro's/con's of wide vs narrow interfaces.

Whether an interface is 'wide' is irrelevant to a proof tool.
All that matters are the artifacts assigned to types, and whether the
tool can prove a given statement using those artifacts.


>>>I saw the abstraction function...that is fine.....the ABS invariant
>>>would constrain the this function?...i.e. it would be a condition
>>>between domain and codomain of the abstraction function?

>>The ABS invariant is a property of the abstraction (ie the ADT) .
>>It is something that is true of the abstraction regardless of the
>>implementation (representation) .

> an example?

A very simple one : collection types.

elements() >= 0
empty() = (elements() = 0)

The above is always true of the abstraction (collections) regardless of how
the collection may be implemented.


SP>Y implementors can play with X.REP forever and a day, but defects will be
SP>found by the REP invariant (if not also by the ABS invariant) .

>>>how will the invariants tell me they have 'found' the defect?

>>The same way all DBC violations are found.
>>At run-time. With the identity given for the REP invariant that failed.

> OK there are theorem provers around

Tools have been around for ages (Larch, SPARK etc) .
Whether they are usable/practical for particular development envs is
another story.


> ...the compiler can tell you....see spec#.

Oh great, a specific tool for a specific (poor) prog lang ...


Regards,
Steven Perryman

Responding to Mark Nicholls:

This conversation seems to be going all over the place, so I'm guessing
I have not explained myself well. Let me start again.

When you are implementing a class, you know the invariant, and you know
which fields, if made public/protected, would allow outsiders to break
that invariant. You know which methods have contracts that have
post-conditions which conflict with the invariant. If you don't know
these things, you have no business implementing the class. The things
that would allow outsiders to break your invariant should be made
private, for the rest, it doesn't matter what access level you give it,
so you might as well make it public.

Whether the various implementations you provide for these features are
error free is irrelevent to the theoritical decision to make the
method/field public or private. We all write bugs on occasion, but we
can't assume a priori that every method we write, no matter how
thoroughly tested, is going to fail.

Even given the above, I feel it is important to satisfy the UAP so in
languages like C++ and Java, I make all fields private and implement
getters and setters.

On Wed, 17 Jan 2007 03:05:28 GMT, Daniel T. wrote:

> Responding to Mark Nicholls:
>
> This conversation seems to be going all over the place, so I'm guessing
> I have not explained myself well. Let me start again.
>
> When you are implementing a class, you know the invariant, and you know
> which fields, if made public/protected, would allow outsiders to break
> that invariant. You know which methods have contracts that have
> post-conditions which conflict with the invariant. If you don't know
> these things, you have no business implementing the class. The things
> that would allow outsiders to break your invariant should be made
> private, for the rest, it doesn't matter what access level you give it,
> so you might as well make it public.

This looks good and reasonable.

The problem is, not with your rule, which is IMO right and good, that the
invariant of the class is unknown. People use the invariant of the type
instead thinking that it would be one of the class and run into problems
later.

> Whether the various implementations you provide for these features are
> error free is irrelevent to the theoritical decision to make the
> method/field public or private. We all write bugs on occasion, but we
> can't assume a priori that every method we write, no matter how
> thoroughly tested, is going to fail.

Agree.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Daniel T. wrote:
> Responding to Mark Nicholls:
>
> This conversation seems to be going all over the place, so I'm guessing
> I have not explained myself well. Let me start again.

I think my brains being going all over the place a bit.

>
> When you are implementing a class, you know the invariant, and you know
> which fields, if made public/protected, would allow outsiders to break
> that invariant. You know which methods have contracts that have
> post-conditions which conflict with the invariant. If you don't know
> these things, you have no business implementing the class.

yes OK..

> The things
> that would allow outsiders to break your invariant should be made
> private, for the rest, it doesn't matter what access level you give it,
> so you might as well make it public.
>

hmmm....still not really convinced by that as an engineering rule of
thumb......I have had a minor penny drop, by my instinct is, your
design a class to implement an inteface, you do not expose stuff that
is incidental to that interface because it may be useful, from a
versioning/subtyping perspective you are making your life more
difficult than it needs to be as all subtypes/version of this code must
also implement these things....yet they seem to be incidental to the
purpose of the class....so make them private.

> Whether the various implementations you provide for these features are
> error free is irrelevent to the theoritical decision to make the
> method/field public or private.

Maybe we'll clarify with an example.

interface Vector
{
VectorAdd(Vector);
}

interface Vector
{
void SetX(int X);
void SetY(int Y);
int GetX();
int SetY();
VectorAdd(Vector);
}

I agree the 'science' tells me it 'does not matter' if I expose
SetX,SetY etc

my original specification tells me that I need to have a vector class
that supports adding of vectors.....I may as well expose the underlying
implementation as it does not matter?

now I want to optimise my system to work on a system that requires
polar coords....so I want to redevelop my implementation of
Vector.......now *I do not know* if any clients have been written that
access SetX,SetY, GetX,GetY.....I know they did not need to do this,
because they could create any vector they liked through
construction.....but now I have to implement polar to cartesian
conversion just in case......more complexity => more bugs & more cost.


> We all write bugs on occasion, but we
> can't assume a priori that every method we write, no matter how
> thoroughly tested, is going to fail.

correct....but unnecesary coupling and complexity give rise to
unnecessary code and unnecessary bugs and unnecessary cost.....a laisez
faire approach allows unnecessary coupling.


>
> Even given the above, I feel it is important to satisfy the UAP so in
> languages like C++ and Java, I make all fields private and implement
> getters and setters.

UAP?

why? surely the science tells you it doesn't matter?

(sometimes I make them public to minimize complexity!)