in reply to Re^2: Interfaces for the masses!
in thread Interfaces for the masses!

In many ways, that's the beauty of perl. Unlike some other languages (oft referred to as "B&D" languages for the tight restrictions they place on you, and the penalties for trying to do something outside of their box which can be severe), Perl is good at letting you do things that the author of the code never thought you could do.

My favourite examples have been one of my coworkers who was tasked with creating a certain module. He placed enormous amounts of defensive code in there to ensure all the parameters were passed in the way he envisioned that they should be. After a few code reviews, I had most of those removed, and then showed him a piece of code I wrote to use his module in a way that he couldn't imagine was supposed to work. But because I could overload, override, and generally muck about, creating interfaces that didn't quite do what he thought they should, I could take advantage of his module to do some core piece of work for me. And, like all good cases of code reuse, when bugs were fixed or features added, I got them for free.

He wasn't a complete novice in perl programming, but has never been as "plugged in" to the community as I have been, and simply had not been exposed to much of the power of perl. And I wasn't doing anything extremely unique, either - passing in handles to "stringy" files or even just \*DATA, where he was expecting everything to be real actual files. He was just amazed at what I could do with his interface if he'd just relax and let me do it.

I used to write B&D code, too. But even in C++, which is still among my favourite languages, if not my outright favourite still, I always found restrictions on what I could do annoying, while perl's free-for-all has been quite liberating. What I've found is that B&D programming assumes that the person writing the library (or reusable code) is smarter than the person using the library, while Perl accepts that the user may be smarter than the library/module author.

If I really want to know if some object ISA different type, I'll check via the isa method. But usually, I just can if the object CAN do something, not why it can do so. Then I trust that when I call that method, it'll do something useful, and that the person who gave me that object in the first place knows what s/he is doing. After all, that person may just be smarter than me. (At least as far as perl and/or programming is concerned ;->.)

Replies are listed 'Best First'.
Re^4: Interfaces for the masses!
by rvosa (Curate) on Mar 24, 2006 at 01:23 UTC
    I am no fan of B&D (in programming, in any case) so I see what you're saying. But here's what I'm wondering about - the responses I've seen here suggest:
    • duck typing using can
    • class checks using isa
    For the former, I like that it is independent of the object's inheritance tree - but it doesn't always convey the same amount of information. For the latter, my point was that using isa to check for interfaces rather than, say, the class with the implementation code would give you greater generality and abstraction. I'm not sure how that's B&D.