Re: The Null Mull (or, when OO needs more O)

[dragonchild]

So, for not too much work, we get a way to not break method chaining, don't have to use eval {} to catch broken code, don't need exceptions, and it can fit into what we're already doing with all of our other objects.

Would you mind going into a little more detail as to why method chaining without exceptions should be done? Most likely, you will still

• have to check the return value
• have to figure out where in the chain things broke
• have to handle that error somehow in some readable fashion

It sounds like a lot of work for the ability to have some admittedly very nice syntactic sugar.

Personally, I haven't ever seen the need for chaining methods like that. This may be because I haven't set my classes up in such a way as to provide for it, but wouldn't that be a more Perlish way of doing things? As Larry is quoted in the Cookbook, "The trick is to use Perl's strengths rather than its weaknesses." It sounds like you're trying to get another language's strength - method chaining - and shoehorning it into Perl without the infrastructure that goes along with it.

I'm just worried that this will be a maintenance nightmare. I would hate to come along as a consultant and be handed this stuff that uses chaining out the wazoo and tries to get cute with an AUTOLOADed everything object that overrides undef or falsehood and ...

See what I mean?

[brian_d_foy]

Before I start, I'm not saying that you should use this in every situation. It has to fit the problem you are trying to solve. If you are in doubt about whether it fits into your problem, it probably doesn't.

That said, I think I've already covered your questions. You can still check the return values. If you got the error object, that's a failure. You can also figure out where things broke. That's an example in the original post. As for readability, you simply check the result and handle the error. Remember, I'm talking about the concept, not the recipe. If you understand the concept, you can implement it in several ways.

People seem quick to wrap an eval around code

my $result = eval { ...code...  }; if( $@ ) { ... }

This metaphor gets rid of some of that kludgyness. Now an error is handled as normal program flow rather than an exception. Add logging and warning capabilities and other things behind the scenes instead of the script level.

my $result = ...code...; if( is_error( $result ) ) { ... }

This isn't syntatic suga. It's not extra syntax at all. It's less stuff at the script level. The program is designed to handle errors, not patched to catch them.

Don't get caught up in the method chaining. It's just one example. It's not always up to me what things I have to deal with and who else is writing code. I have to make things keep working even if other people chain methods. You don't have to shoehorn method chaining into Perl, either. It's there already. If you don't like it (and reasonably so), you don't have to design for it and you don't have to use it when the interface allows it. That's a personal preference, though. Other people do it, and I have to live with that. I'm trying to get away from people shoehorning exceptions into Perl, which is a true weakness. That's what all the eval and die nonsense is. ;)

It's not a maintenance nightmare at all. You simply document how to check a return value. The scripter doesn't have to know anything about it. They just use the interface. They get a result, and test that result for true or false (or however the rest of the system does things). The mechanics are homologous to testing a result code through a method like a lot of modules already have in their interface. If the coders aren't checking return values, the program still breaks at the same point.

But again, let me emphasize that you don't have to use this. Don't go looking for places to use this. Just file it away in your toolbox. Someday you might run into a situation where its useful, and those situations will come to you (not the other way around).

[dragonchild]

It's not a maintenance nightmare at all. You simply document how to check a return value. The scripter doesn't have to know anything about it. They just use the interface. They get a result, and test that result for true or false (or however the rest of the system does things). The mechanics are homologous to testing a result code through a method like a lot of modules already have in their interface. If the coders aren't checking return values, the program still breaks at the same point.

brian, brian, brian. *sighs* If only 90% of people who type Perl code into an editor¹ actually followed a tenth of what you say. But, alas, that is not the case. In fact, it is so often not the case that ... let's just say they already have enough rope to hang themselves with.

You simply document how to check a return value. The scripter doesn't have to know anything about it. They just use the interface. They get a result, and test that result for true or false (or however the rest of the system does things).

In 7 jobs located in 5 states over the last 4 years where I've used Perl, documentation was done in exactly two places. In one, a multi-billion dollar consortium that handles 40% of all credit card transactions, the documentation was done so we could have something to review code from. It was never actually kept up to date, nor was it any form of developer doc. In the other, a 100-million dollar insurance firm, since I wrote the system from scratch, I documented exactly enough for my protegee to keep the system running.

What happened in the other 5 jobs? Bupkus! That's what happened. Motorola, BankOne, a tiny startup ... none of these firms documented their Perl code, processes, APIs ... nothing! You cannot assume anyone will document code, let alone Perl code. Remember - Perl isn't a programming language, so it's got to be really easy to figure out.

If the coders aren't checking return values, the program still breaks at the same point.

Actually, it won't. See, 90% of all Perl code currently running on some production system somewhere doesn't

• use strict, warnings, or -w
• check return values from system calls
• check return values from DBI calls
• use taint (I'm guilty of this one)
• use hashes in any reasonable way

As a consultant, that's the code that I have to support. And, because the people who wrote this pus-dripping, camel-vomiting dreck either have CS or MIS degrees, they obviously know everything there is to know about Perl. So, when someone comes up and says "Here, let's go ahead and make Perl feel more like VB", they're going to go "Ooooh!" and jump all over it.

Except, they'll screw it up. But, since these flea-bitten, dog-kissing, motherless goats wouldn't recognize a development process if it painted itself pink and purple and danced naked on a bar wearing a fruit basket on its head, they DIP² like it's 1959. Once it's in production, getting it out is like giving medicine to a toddler. Even though the child is only 30 inches talls and 25 pounds, it still takes 2 adults to hold the squirmy bastard long enough to squirt 4ml of pink goop into its mouth³.

While this is partly tongue-in-cheek (could you tell?) ... I'm also being deadly serious. This proposal requires a lot of API documentation. I can definitely see a CPAN module using it, especially one like Mail::Sendmail for the example you gave above. Advocating development shops use it when the language doesn't have explicit support built in can be ... well ... disheartening for those of us who will have to maintain said code. I mean, can't you see how this is hurting the children?!? Think of the children, brian! The children!!!

1. Please note that I did not say Perl coder / hacker / programmer / etc. I certainly did not want to imply that 90% of people who type Perl actually know what they're doing.
2. DIP = Develop In Production. Only slighly better is TIP (Test in Production). And, yes, 90% of all Perl code in the world is either DIPed or TIPed. Believe it, or not.
3. I'm not kidding. You'll want 3 adults if you don't want pink goop all over your shirt.

[brian_d_foy]

If you're dealing with undocumented code, then it doesn't matter what the code actually is: it's a maintenance nightmare even without very simple technique. Let's blame the right thing, and not transfer your rage onto the innocent. :)

Other people may suck, but that doesn't mean I need to.