All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
The Perl Book We Need
How often do you see this in code?
sub new {
my $class = shift;
return bless [] => $class;
}
Not very often. However, I'll bet you often see errors like this:
my $cust = Customer->new($id);
# violates encapsulationprint $cust->{name};
# violates encapsulation again! (unless internal):
if ( $cust->_preferred ) {... }
# bad interface if the following fails:
$cust->set_name($cust->name);
# Hello Demeter! (Yeah, this is contrived)
my $office = $cust->salesman->manager->office;
What I would like to see is a book which focuses on OO programming for Perl, but with two primary considerations. The first is to focus primarily on what people are likely to encounter in the wild: blessed hashrefs. The second consideration is teaching them how to think about OO programming.
Intermediate Perl and Object Oriented Perl both have great things to say on these topics, but neither is quite what I would like to see out there. Unfortunately, many Perl programmers learn the syntax of OO in Perl but they don't learn OO. Blessing a hashref isn't enough. Instead, I'd love to see more Perl programmers who can reasonably discuss:
- Responsibility-driven design.
- The difference between class and instance data/methods.
- How inheritance breaks encapsulation.
- When to throw exceptions.
- Composition via delegation.
- Class consumers versus class cooperators.
- Why the Liskov Substitution Principle is important.
- Polymorphism and allomorphism.
This wouldn't be a design pattern book. This would not be a syntax book. It would be something which would open up the eyes of Perl programmers regarding OO, but it would be straight-forward. Want class data? Use Class::Data::Inheritable and explain the concept. Need delegation? Use Class::Delegator and explain the concept. It's not to claim the the tools the book uses are best practices. It's to claim that the ideas the book uses are best practices. That's why it would mention blessed array references, but all examples would be blessed hash references. That's what you're likely to see and it's more important to focus on the concepts than the implementations.
So, um, somebody go out and write the damned thing.
-- Jarkko Hietaniemi
Read more than just Perl books! (Score:2)
But, this book wouldn't sell. It would be a great book, but no one would buy it (where no one means fewer people than it takes to keep the economic incentive above working at Starbucks instead).
I don't see the word "Perl" in the title magically making this a sellable or interesting book. People interested in good design are the same people that read about design despite the language.
I here rumor that the Perl book topics wi
You don't want a book... (Score:1)
And unfortunately, for the most part (rare exceptions like Perl Best Practices excluded) books don't educate the masses.
Things like perlcritic rules are far more likely to have the impact that you want.
I think there's a number of interesting perlcritic rules that could be implemented based on your examples (most of which I agree with)
Damian covers these concepts... (Score:2)
Liskov can bite me (Score:2)
It's important for academics who are more concerned with being correct than useful.
Override nothing! Delegate everything!
Ok, maybe I'm a wee bit bitter after losing a debate about Pathnames, Strings and subclassing.
Re: (Score:2)
I think you must be thinking about something else. Liskov doesn't say anything about not being able to override anything. It merely states that a subclass must be substitutable for the parent class without affecting the correctness of a program. You can override all you want, just make sure that the interface doesn't change.
I don't get it (Score:1)
Re: (Score:2)
It's a question of encapsulation. Imagine that the Salesman class no longer has need of a manager accessor, but you still need to know which office the salesman is with. You might get a office method pushed into the Salesman class. Then, every place where you have the above code needs to be changed to:
If that's called a lot, it can be a maintenance nightmare.
However, what if you have this?
Re: (Score:1)
Re: (Score:2)
You're welcome. It's not exactly intuitive. Took me a couple of tries to get it :)
Re: (Score:1)
Thank you. I hadn’t realized Moose’s powerful delegation mechanisms we’re more than handy shortcuts. This provides an excellent use case for them.
For those who don’t know Moose every attribute object can have a handles er … attribute … so the example here can be defined like:
Re: (Score:1)