5 ms·
Great talk! I've never posted before, but I'm inspired to today. Forgive me if my code is formatted terribly this post. I used Perl back around 2000, like ever
by joel_perl_prog 14y ago
Great talk! I've never posted before, but I'm inspired to today. Forgive me if my code is formatted terribly this post.
I used Perl back around 2000, like everybody else, to make CGIs. Then went away from it for a long time. But I've used Perl over the last year to create a large DMCA takedown system, the bulk of which is spidering and analyzing web pages for infringements. Torrent trackers, one-click file download sites, etc.
It's been a beautiful experience. The code runs quickly (for a scripting language), and CPAN is AMAZING. I feel Perl was the best choice for this project, and since I enjoy the language--and trust me, it's NOT line noise: these aren't little scripts, this package-based, documented, modular software development, the likes of which people normally associate with Java (for instance.
I have to say I disagree with one point in that talk. I don't think there are "too many" ways to do OO in Perl--and this sort of ties into his gripe about "@_" and slurping in subroutine arguments, which I think is pure joy. I'm not certain, but I think Larry Wall got this from Lisp. Please correct me if I'm wrong on my history there.
Anyway, in one package that I use as an object, I have this code:
#/ @param object $this an Offense::Analyzer
#/ @param string $event an EVENT_x constant value
#/ @param int $targetId a target id
#/ @param int $obvious TRUE for obvious offenses, or FALSE
#/ @param int $same TRUE for offenses found on the same target, or FALSE
#/ @return int the value for the given event, or undef
sub getEvent($$$$$) {
my ($this, $event, $targetId) = (shift, getEventFor(shift), shift);
my $obvious = getObviousKeyFor(shift);
my $same = getSameTargetKeyFor(shift);
return undef unless $this->hasTarget($targetId);
$this->{'data'}{$targetId}[$obvious][$same][$event];
}
And I supplement that code with the following convenience getters:
sub getIgnored($$$$) { shift->getEvent(EVENT_IGNORED, @_) }
sub getNotified($$$$) { shift->getEvent(EVENT_NOTIFIED, @_) }
sub getQueued($$$$) { shift->getEvent(EVENT_QUEUED, @_) }
sub getRemoved($$$$) { shift->getEvent(EVENT_REMOVED, @_) }
I love the convenience of being able to use the incoming arguments array in this manner. In fact, because you explicitly pass the object reference as the first argument to methods in Perl, I even have this:
#/ @param object an Offense::Analyzer
#/ @param string an EVENT_x constant value
#/ @param int a target id
#/ @return int the value for the given event
sub getEventTotal($$$) {
int(getEvent(@_, TRUE, TRUE)) +
int(getEvent(@_, TRUE, FALSE)) +
int(getEvent(@_, FALSE, TRUE)) +
int(getEvent(@_, FALSE, FALSE));
}
Those are not static method calls (so to speak--package sub calls), but are object method calls. I love that convenience.
Does your fluency need to be very high for this to seem like a good idea? Probably. And in this manner, Perl can never compete with Python. But I guess my argument is similar to the argument a lot of Lisp dialect programmers make: I'm an advanced user, I don't need to be babysat, I can take care of myself, and I'm ok with exploiting the expressiveness of the language.
- rotten 14y agoWell, there is 'Moose' if you want to do OO Perl: http://moose.iinteractive.com/ http://moose.iinteractive.com/ Some folks I know swear by it. I just find Perl hard to read and not very intuitive. My perl loving friends, on the other hand, claim the opposite. I guess it depends on how your brain works and what you are used to.
- falsedan 14y agowhy aren't you using POD for your documentation why are you mistakenly using prototypes for function signatures
- joel_perl_prog 14y agoYou're right on both counts. I would never perldoc my private code...I already don't use it for installed modules. So that's a personal preference. The prototypes issue is spot on. They're ignored during compilation when dispatching isn't clear ($obj->method() ... which subclass?). Most of my subs aren't called that way, so I do get argument checking, which has saved my butt many times, so I just make a habit of always using prototypes. They've been useful for me: that's all I've got there. I could easily be wrong. And that goes for my whole coding style. You could easily say it's wrong to use "@_" the way I do, which I feel is incredibly convenient. I'm not saying it's a best practice. Maybe it isn't. But for me, it presents no obstacle, and I feel the code is perfectly clear. In in fact, having to enumerate every single argument merely to pass them along, in the same order, to another sub...to me, that seems like a terrible idea. Some people prefer that verbosity (or clarity, if you like). I don't think it's necessary.
- falsedan 14y agofair reasons both