I've recently been writing Perl objects until they come out of my ears. This has meant a great deal of re-reading of Mr Conways book, and a lot of soul-searching as to which aspects to keep and which are over-engineering for the requirements and the platform.

Since Perl's implementation of OO is commonly used with a hash, one hash for a class and all it's 'parents'. To avoid collision between names of inherited attributes a namespace is defined for each package and prepended to the attributes of an object. This is a poor summary of section 6.2.6 of OO Perl by Damian Donway.

Well it set me to thinking, that since I was brought up believing all properties of an object should be viewed through accessor methods, and altered through mutator methods, one way of achieving this was to slap on a long namespace to stop people tampering, it seemed a little more dictatorial than the '_' affordance, although I stuck to that too. 

$object->{_id};
$object->{_private_property_of_template_called_id_leave_it_be};

# Both could then have an accessor method, respectively
sub get_id () { $_[0]->{_id} }
sub get_id () { $_[0]->{ _private_property_of_template_called_id_leave
+_it_be
 } }

# And each would be called 
$object->get_id();

[download]

My reasoning being, the the major reason for people using the properties rather than the accessors, which might perform other duties, was mis-placed laziness.

Obviously, I hope, you can see that I've exagerated the length of the property, but does this makes sense to use? I really am in two minds as to whether this is a good thing, so I thought I'd post it here as people have some pretty strong views on OO...

--

Brother Frankus.

¤

Replies are listed 'Best First'.
Re: A new take on affordance.
by Biker (Priest) on May 16, 2002 at 14:17 UTC

    It's a contract. And you should write the contract.

    When you build your class, and if you expect anyone elses application to ever instantiate objects of your class, you must provide the proper documentation. (Having said that, it's always good to provide the docs, even if it's only to simplify your own life n months later. ;-)

    The contract is your own POD. Provide a POD for the module, inside your module and also deliver it together with the module.

    Anyone that is going to use your module should follow your contract. In your contract you state that "If you use this method, that will be the result". For those that do not respect the contract (and some will try to violate it) the only thing you can say to them is "tough luck" when they complain that your latest release of your module brakes their application. (Assuming that you stick to your own contract. ;-)

    OTOH, if you do provide what I call a contract, you are free to make any changes to the internals of your object, as long as the module interface (that you promised in your contract) doesn't change. If you need to change the interface, you might need to re-negotiate it, all depending on your situation. For instance, is this an in-house module where youre business relies on it's behavior, etc.

    There's no way you can make sure that no one can access the internals of your module. Not in Perl, neither any other programming language that I'm aware of. Produce a class in C++, compiled and distributed in it's binary form, and anyone with enough skills can manipulate the properties of your object. Crackers do it all day long with a binary editor/debugger.

    Everything went worng, just as foreseen.

[reply]
Re: A new take on affordance.
by broquaint (Abbot) on May 16, 2002 at 13:25 UTC
    A long property name is certainly going to discourage people from using them directly (we are perl programmers after all ;-), but there are other options.

    For example if you're just creating read-only accessors then you could use the closure method for creating RO accessors as described in Tom Christiansen's perltoot.

    There's also Michael Schwern's Class::Accessor which will perform all the accessor creating magic for you.

    As people have previously discussed, OO in perl is like asking people not to come into your house as opposed to standing at the front door with a shotgun and a twitch in your right eye. So you may want to fall on the B&D side of property accessors or take the perl approach and ask people kindly not to mess with the object properties as it could do any() or all() of x,y, and z.
    HTH

    _________
    broquaint

[reply]
Re: A new take on affordance.
by Caillte (Friar) on May 16, 2002 at 15:35 UTC

    Having the code for an object open and publicly readable is both an advantage and a disadvantage, sure, but from looking around at the other perl programmers I have known it is not really a problem. Sure, you can open up the object, look around, even edit it to suit your own needs, and you can access variables within the object without going through the method interface. However most people dont and, I think, with experience even those who do will stop over time. The reasons for this become obvious as you become more experienced with the rationale behind OO design. While you could access the data directly, avoiding the methods, it is not a good idea. What if the designer changes the data type between revisions? Such a change is perfectly acceptable in OO design as the underlying data is supposed to be opaque to the user of the object. This means that thingy.pm version 1 could store it's data as a scalar while version 2 stores it as part of a hash. However, if thingy.pm has been written correctly, thingy::get_data will return the same thing regardless of version.

    Once you know this then it quickly becomes a good idea to just use the methods and leave the data as it is.

    On the other hand, what perl programmers have over C++ (for example) programmers is direct access to the source code of that object. Now, while playing with it is not a good thing, these modules then become a vast and wonderful knowledge base that the programmer can dip into at will to help solve his or her problems.

    So, if you have any sense, pretend that you cannot see into a perl object, but also make the most of the fact that you can to become a better programmer ;)

    I did, and still do ;)

    This page is intentionally left justified.

[reply]
Re: A new take on affordance.
by Dog and Pony (Priest) on May 17, 2002 at 08:31 UTC
    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.
[reply]
      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]
Re: A new take on affordance.
by P0w3rK!d (Pilgrim) on May 17, 2002 at 15:02 UTC
    Yes it saves electrons to grab a property directly. However, I learned the same way you did brother. If you want your code to make sense to "everyone", then I would stick to using accessor/mutator methods.
    ..And such are the words of '00'.
    -P0w3rK!d
[reply]
Re: A new take on affordance.
by Aristotle (Chancellor) on May 18, 2002 at 05:02 UTC
    I think you shouldn't go out of your way to make it hard. As has been said, write a proper contract in your POD, and let people bear the consequences if they break it.

    Because occasionally, someone might want to break it with good reason. It is rare indeed, verily so, but it happens, as not every class is as well designed as one might wish for. No need to make things harder on people who know what they're doing.

    Makeshifts last the longest.

[reply]

Back to Meditations