in reply to Closure objects with public, private, and protected fields

Let me first say that I was once like you are, I was obsessed with trying to make Perl OO be more like other, "stricter" OO systems. I even wrote and released a module to CPAN (see Devel::StrictObjectHash) to do exactly what you are doing here (I used tied hashes though, instead of closures). I also wrote many "protected" and "private" methods which died if the wrong person touched them.

And then, after a few years of this, I realized that never once did I ever actually need any of this code (and the computational overhead that came with it). You see, I realized that I had just built in a bunch of checks, which would always return false, and never execute, because I always used my modules correctly. I then also realized that all my co-workers who used my code did the same. And I would venture to guess that any of the users of my CPAN modules, they also used them correctly. And why do I think this is so?

Because that is how I documented them, plain and simple.

I basically came to the realization, that this is a social problem, and not one to be solved with code. If my co-worker is violating my encapsulation, he/she is wrong. If they have to violate my encapsulation to make things work, then my design is wrong.

Now, from a purely code point of view, I also noticed something about your code (which was always in my code too), especially in how you deal with private and protected methods. You suggest that adding this at the begining of your code for a private method: 

    caller(0) eq __PACKAGE__ || confess "setQuackBehaviour is private"
+;

[download]
and this for protected methods: 
    caller(0)->isa(__PACKAGE__) || confess "setQuackBehaviour is prote
+cted";

[download]
Both of these methods ignore the possibility that an ancestor class might implement a public version of setQuackBehaviour. Now, my Java is a little rusty, so I don't recall if that is even possible in Java, but that matters not since you are not explicitly disallowing that behavior here anyway.

To properly implement public/private/protected methods, you need to have access to Perl's method dispatcher itself, and that is, I'm sure, not possible without patching perl itself. And to really implement this kind of behavior effectively and efficiently, you probably need some degree of program analysis and code fiddling/generation, which again means a patch to perl. And by the time you are all done with this, you might as well have just saved yourself the time and used Java/C#/C++ or some other language where you get his for free.

-stvn

Replies are listed 'Best First'.
Re^2: Closure objects with public, private, and protected fields
by Anonymous Monk on Mar 07, 2006 at 19:32 UTC
    If my co-worker is violating my encapsulation, he/she is wrong.

    Unfortunately, management rarely understands, nor cares, which party is "wrong" from the standpoint of computer science philosophy. Mostly, they just care whether or not the code you put into production breaks something; and if your patch to production code breaks something because you foolishly assumed your co-worker wasn't an idiot, you're going to have to answer for your mistaken assumption.

    Never just assume competence on the part of other people, or even yourself for that matter, unless you have absolutely no choice. Double and triple check everything and verify that it is right.

    Reliable systems come from multiple independent verifications and confirmation; not blind faith in the talents of the people working on them.
    --
    Ytrew

[reply]
      Unfortunately, management rarely understands, nor cares, which party is "wrong" from the standpoint of computer science philosophy.

      Yes, I completely agree, but what I am talking about is not "computer science philosophy", but social contracts. Management does understand rules, and if "don't break encapsulation" is a rule, then the fault will be clear. Any team must have agreed upon ways of working, or you find that you will end up with total chaos. And this goes for industries outside of technology too, anyone who has ever worked in a resturant knows this. If you cook staff is not a well oiled and coordinated machine, which is governed by both written and unwritten rules, not only will peoples dinners be late/wrong, but there is a good chance someone could end up in the hospital by the time the night is over.

      Mostly, they just care whether or not the code you put into production breaks something; and if your patch to production code breaks something because you foolishly assumed your co-worker wasn't an idiot, you're going to have to answer for your mistaken assumption.

      Well if you are in a position of responsibility, you should always assume everyone else is an "idiot" unless proven otherwise. This is not to say you should walk around with a chip on your shoulder and look down your nose at them. Only that if it's your ass is on the line, you need to make sure your covered.

      As for deploying/patching production and having things break, that is what staging/QA environments and regression test suites are for. If you are not using them, then you are already in deep trouble so what's a little bit more :P

      Reliable systems come from multiple independent verifications and confirmation; not blind faith in the talents of the people working on them.

      Of course, and through those "multiple independent verifications", someone would (I hope) spot the encapsulation violation and it would be addressed, and the programmer would recieve thirty lashes and placed in stocks to serve as a warning to others.

      -stvn
[reply]
      how did your co-workers mistakes end up in production? seems to me you didn't double check and verify enough.
[reply]

In Section Meditations