Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by Juerd (1796) on 2008.06.23 21:23 (#63563) Homepage

    Seriously, I think the greater problem about identifiers rather than context. To stay with your example of "extract", that's a verb. When a method has a verb as a name, I expect it to do whatever the verb says. As the return value, I wouldn't (ever) expect a list, but instead some true value if the action has succeeded, and a false value if it hasn't.

    A method that returns something, should have a noun as its name, that describes what it returns. Even if it's something as simple and perhaps ambiguous as "field", it's very useful and good autodocumentation. And best of all: you can make a plural out of most nouns. A method named "fields" clearly says that it's going to return a list. And for a method that so clearly returns a list, the case for returning an arrayref in scalar context is made almost intuitively.

    Given a line like:

    my $field = $something->fields;

    I'd immediately notice the asymmetry, which can be solved in numerous ways, list assignment being the obvious one if there's no singular field method:

    my ($field) = $something->fields;

    If you're reminded of Joel Spolsky's article about making wrong code look wrong, that's great. If not, you should probably go (re)read it :)

    With functions (rather than methods called on objects) data doesn't go anywhere else than the return value - after all, variable sharing is bad. However with methods the data generated by the method might stay in the method. You really need a good system of identifiers to consistently indicate what happens.

    Good identifiers turn context into a really useful concept, while bad identifiers make it a messy thing that involves lots of guesses and/at design decisions. But instead of identifiers, your post revolves around Template Toolkit's handling of list context. That's caused by their awkward combination of Perl and a language that doesn't have context and lists. TT may be written in Perl, but it isn't Perl - or even Perlish. In fact, its language appears to be designed with a strong anti-Perl bias. Yet at the same time, using Perl code with it is encouraged: look how easy it is to use your existing Perl objects in TT!

    Indeed you have to ask if this TT design mistake is in the interface itself. The root of the problem is that Perl does something that most (all?) other programming languages don't do. And that makes it incompatible. Bad Perl? No, I really love context and lists. They make perfect sense within Perl, and fit my thought patterns well. Just not in PHP, Ruby, Python, and indeed... Template Toolkit.

    • You're right that good design starts with good naming. Unfortunately the idea of systemically basing your method and class names on grammatical notions is one that I was not exposed to until I read Perl Best Practices. Which did not immediately sink in because it was formulated in a very abstract manner and it took a while for the advice to sink in.

      Needless to say I wrote that module before this point.

      Still when you're facing a design mistake, it is worth thinking about all of the potential contributing f