Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: How to measure Perl skills?

by kvale (Monsignor)
on Mar 22, 2004 at 23:57 UTC ( #338848=note: print w/replies, xml ) Need Help??

in reply to How to measure Perl skills?

All of your reqirements are needed to write a simple OO module. So pick a simple spec, e.g., a Book class with title, author and ISBN as object attributes and number of books as a class attribute. In an hour, someone versed in OO Perl should be able to sketch out a solution.

Extra points for

  • using strict and warnings without being told to
  • using the two arg bless for inhertiance down the line
  • encapsulation of class attributes (if you care about that sort of thing)
  • Automating get/set methods with AUTOLOAD
  • test script


Replies are listed 'Best First'.
Re: Re: How to measure Perl skills?
by Ovid (Cardinal) on Mar 23, 2004 at 00:10 UTC

    That might work given the short time alloted for the test, but I wouldn't give them bonus points for the two argument bless. I assume that any competent programmer is going to do that (unless they are explicitly forbidding subclassing). I would simply dock them if they didn't use the two argument form.


    New address of my CGI Course.

      please tell me that it counts as the two-arg form of bless if you let Class::MethodMaker generate your 'new' for you
        See, this is why I love PM! Somehow I wasn't aware of the existance of this fine looking module. I ask a question about testing, and I learn something new (ok, lots of things).


Re: Re: How to measure Perl skills?
by hardburn (Abbot) on Mar 23, 2004 at 14:18 UTC

    encapsulation of class attributes (if you care about that sort of thing)

    You should care. Otherwise, why are you bothering with OO at all?

    Automating get/set methods with AUTOLOAD

    No, that breaks encapsulation. AUTOLOAD isn't the best way to do that, anyway. Putting sub refs directly into the symbol table at runtime is much faster.

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      A bit OT, but I think you've given a simplified answer to a simplified question.

      I'm not sure how AUTOLOAD breaks encapsulation, as the AUTOLOAD code can decide what is allowed and what isn't [die "Horribly" comes to mind]. And AUTOLOAD only needs to be called the first time an unregistered method is requested -- the symbol table hockey will avoid future AUTOLOAD calls on that method, at least.

      But maybe you meant to just generate all of the sub refs at initialization, so all the methods didn't need explicit coding, just a method factory? Autogenerating all method code is probably faster than the AUTOLOAD runtime on just one method (for some values of all method code).

      On further reflection, it sounds like we might be in violent agreement.

      Quantum Mechanics: The dreams stuff is made of

        This is a nit but anytime the symbol table is altered the method cache table is invalidated so all your calls to $obj->foo have to do the full @ISA check again as well. That makes it nice to do symbol table updates only as needed or preferrably before the cache is going to be desired.

        If you're using AUTOLOAD instead of methods like this:

        sub foo { my $self = shift; $self->{foo} = shift if @_; $self->{foo}; }

        Then you're breaking encapsulation. You were better off just providing a hash and a few subroutines to work on it. In a well-designed class heriachracy, you will need very few accessors/mutators (i.e., methods that directly access the internal attributes of the object). OOP purists will tell you that you need none at all, but I find that in practical code, you'll have a hard time factoring out the last few.

        (I suspect the reason for this is a diminishing-returns thing. You can theoretically get rid of all accessors and mutators, but eventually the work required to do so just isn't worth it.)

        This isn't the only use of AUTOLOAD, but it is almost certainly the most common.

        Ignoring OO purity for the moment, AUTOLOAD still isn't the best way to get accessors/mutators, provided you know what fields you want to work with in advance (if you don't, then you'll probably have to use AUTOLOAD). Example:

        foreach my $field (qw/ foo bar baz /) { no strict 'refs'; *$field = sub { my $self = shift; $self->{$field} = shift if @_; $self->{$field}; }; }

        This gives you a little overhead when the module is loaded. It has the advantage of being as fast as a regular method lookup, in addition to saving memory (because it's making a reference to the same subroutine each time).

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

Re: Re: How to measure Perl skills?
by optimist (Beadle) on Mar 23, 2004 at 19:28 UTC

    Thanks, yes. This would probably get the job done, and make management happy. Taking Abigail's excellent advice, I would ideally have the candidate talk me through the solution, but perhaps simply on a whiteboard. What I'm leaning towards now is something they could think through and type up in 30 minutes or less, followed by a chunk of time in which they could walk me through their solution and explain it.

    And although I like to see (and create) test scripts for most non-trivial code, I don't think I'd expect anyone to write one given such a short time to complete the whole task. But 5 or 10 lines of comments (or POD) explaining basic design decisions would be a major plus in my book.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://338848]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2017-04-24 01:16 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (433 votes). Check out past polls.