(aka, "at least he said I'm competent!")
Back in April Mark-Jason Dominus visited Pittsburgh in support of his upcoming book Perl Program Repair Shop and Red Flags.[1] Actually, "in support" doesn't quite capture his intent. Instead of a typical process where the author dictates from his experience about X technology or Y methodology, MJD is creating a book showing standard programming and design mistakes people make and how you can fix them. It's similar to refactoring but the focus is on real-world problems rather than the standard examples (bonus calculations, calculators, scoring games, etc.).
The announcement to the group asked people to send in their code for MJD to fix up. Of course nobody did, I think partly because a lot of code people work on is internal and they're not sure whether it can/should be shared with the world. And partly because nobody likes to see their code torn up in front of a group of people, much less in a book where it'll be preserved forever.
In the absence of volunteered code MJD scoured the CPAN directories of pgh.pm members, finding Class::Observable which fit the bill very nicely:
We didn't know what he was going to review beforehand, and I came in as they were passing out paper copies of the code, just before he started. I sat down and looked at the paper: 'Observable.pm'. "Aww, shit," I muttered, just loud enough for the person next to me to hear. At least I didn't have time to worry about it beforehand.
Now he's written up a good summary of what he said at the meeting. It sounds more painful than it was, honest. Partly because I haven't touched Class::Observable in a while, partly because he was straightforward and professional (non-personal) about it, and partly because I think I took it in the spirit it was intended.
A couple of the questions he had were easily answered. But the main problem he has with the class is that it doesn't use the object to store data about the object. This is so common-sense that it shouldn't even bear repeating, right? It's a little murkier than that, as he alludes to in the writeup. (The fact that he made the same mistake in something he wrote was comforting.)
The real reason I didn't use the object was that I did not want to touch the object. At all. Why not? My original thought was that I didn't want to assume anything about the object's implementation. This is something you need to worry about in Perl that you don't with languages that are built around OO. Since an object is just a reference with metadata about where it belongs, and a reference can be a scalar, array or hash, you can't assume a way to store object data.
But you can assume methods, which is the whole point of the object anyway. And as Mark showed in his implementation, all you need to do is define a default behavior for the common case (object-as-hashref) and let people implement their own uncommon cases by providing method hooks for them to do so. It's a much clearer implementation and makes a lot more sense.
So my reluctance to touch the object was really a type of cargo cult behavior[2]: You can't depend on object implementations so don't put anything in the object. Instead of thinking about the general problem and the best implementation I didn't even consider a set of solutions because "you don't do that" -- a false trade-off. It's humbling when you realize this sort of behavior in yourself; I don't think I'd make the same mistake today, but maybe I already have and just don't realize it yet.
[1] I heard he did this same talk at YAPC 2006 a few days ago. Hopefully he didn't use my absence to be harsher than he was in Pittsburgh :-)
[2] I seem to remember a great writeup of this from MJD's blog, maybe somewhere else, but I can't find it now. If you have a link please send it on.
Posted from cwinters.com; read original
Re:Just put it in the damn object!
lachoy on 2006-06-30T19:14:22
Yeah, I actually linked to that about mid-way through the post; that'll teach me to bury the lede!mjd on cargo cult programming?
naughton on 2006-06-30T20:36:00
D'Oh! That'll teach me to just skim the article and not follow all the links. I thought I was helpfully providing what you asked for in footnote [2].
But about cargo cult programming, I think you're a little too hard on yourself. You obviously understand the reasons to avoid putting things in Perl objects and how the alternatives work.
mjd sums up my understanding of cargo cult programming in this entry from his File of Good Advice:#11900 You cannot just paste code with no understanding of what is going on and expect it to work.
There's lots of similar "advice" in that file, including the lucid "#11959 Cargo-cult." But that's not really a "writeup", so probably isn't what you're looking for. If anyone else knows of a writeup by Mark Jason Dominus on cargo cult programming and/or behavior, please share.Re:mjd on cargo cult programming?
lachoy on 2006-06-30T22:51:18
A-ha! I remembered it was on his blog, and that it didn't have cargo cult in the title: Creeping featurism and the ratchet effect. In particular, toward the last third of the post:
By saying "if you're not sure, just avoid the problem" we are encouraging this kind of fearful, superstitious approach to the issue. That approach would be appropriate if it were the only way to deal with the issue, but fortunately it is not. There is a more rational approach: you can look it up, or even try an experiment, and then you will know whether the parentheses are required in a particular case. Then you can make an informed decision about whether to put them in.BTW, I have MJD's quotes on my website feeding the quotes at the bottom. If you reload a page a few times you're sure to get one
:-)
