in reply to A new take on affordance.

No reason to make it harder on people that way - reason is simple: people who violate encapsulation should be beaten with sticks anyway.

Nah, I'm just kidding. But anyone who is bypassing your api to access values themselves (perhaps just because you accessor methods do extra stuff?) should know that they "void warranty if opened" as it usually says on most electronic boxes you can buy. They are on their own. And if that turns out to be a bad thing, well, you did tell them, yes? By having accessor/mutator methods, you specifically declare that this is the way the data should be accessed.

Even heavily guarded languages like java provide the same capability to directly access just about anything inside a class - if you choose to. In java, it is called reflection, and as mentioned above, it is possible in just about any language, really. If you want to.

I don't recall exactlty how, but I think that the Camel book had some nifty examples on how you actually could create truly private data, with no possibility (apart from patching) to access the properties or data at all. Take a look at the Object chapter (I think) of that book if it is important with private data.

Life tends to be so much simpler if one just follows the guidelines that are set up. But if you need to break the rules for one reason or the other, it should be easy to find the data you want to manipulate - which might be a reason not to name the property too differently. So that people that wishes to do so, can more easily follow tthe code and extract what they want... with warranty void, of course. :)

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

Replies are listed 'Best First'.
Re: Re: A new take on affordance.
by dsheroh (Monsignor) on May 18, 2002 at 14:27 UTC
    A quick flip through the Camel didn't turn up anything on making truly private data, but the Coriolis Perl Black Book goes into a few tricks with closures to make your private data hard to get at. The ultimate point, though, was that anyone who knows which trick you used to hide the data can still get at it by throwing the right string of puctuation at your object.
[reply]
      In the third edition of the Camel book, it is to be found on page 339, Using Closures for Private Objects in chapter 12, Objects.

      I didn't personally look into it, but the authors of that book seems to think this method is a bit more secure than that...

      Perl offers low-level building blocks that you can use to surround your class and its objects with an impenetrable privacy shield - one stronger, in fact, than that found in many popular object-oriented languages.
      and
      This is a very strong from of encapsulation; not only is it proof against external tampering, even other methods in the same class must use the proper access methods...
      What they are talking about is using a closure as the object itself, and they proceed to give some examples. Like I said, I didn't investigate, so those claims will have to stand for the authors themselves... *grin*. I'd say they should know, though. :)

      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
[reply]

In Section Meditations