Re: Another controversial question
Re: Another controversial question
- Subject: Re: Another controversial question
- From: Chris Gehlker <email@hidden>
- Date: Mon, 03 Sep 2001 08:06:47 -0700
On 9/3/01 1:36 AM, "Ondra Cada" <email@hidden> wrote:
>
It can _not_. It can, of course, mess up thing if you implemented it
>
wrongly; that's not encapsulation violated, but plain old programmer's bug,
>
though ;)
This is starting to sound like just a semantic difference. I used to see
definitions of encapsulation that were built in terms of access. I think
more and more you will see the "consistent state" idea used to define
encapsulation. It doesn't matter much, though. We agree its a bug.
>
That's quite good. You can use valueForKey:@"mean" quite right, just as well
>
as -mean. And if some improper code tries takeValue:forKey:@"mean", you will
>
get a runtime error, just like you tried to send the non-existing -setMean.
>
>
The only (in practice very easily dodged) danger is that you can't have
>
another property by a blind chance named "mean", unrelated to the -mean
>
method and the whole problem, in the class (lest it would be improperly
>
accessed by the takeValue:forKey:@"mean").
If that's the way it works, it's quite a bit safer than I thought. I'm
hampered by having little experience with it and very sparse documentation.
It makes a lot more sense that it would work the way you say.
--
Every society honors its live conformists and its dead troublemakers.
-Mignon McLaughlin, author