in reply to What would you change?

And, the biggest thing is the variable tying system. I love variable tying. But, it should be really be implemented through some form of autoboxing vs. the rather ad-hoc-ish mechanism that is TIE. Having dealt with nearly every intricacy you can with DBM::Deep, there are certain parts I just go "Uhh ... it passes all the tests!" and leave it at that. At the very least, there needs to be a massive amount more documentation of exactly what gets called in what scenarios. But, autoboxing would solve the issue nicely.

Of course, we can't autobox without a solid OO system. I'd just like to autobox with Moose. But, I can't without a performance penalty that's ridiculous above what tie imposes. So, I don't.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^2: What would you change?
by monarch (Priest) on May 17, 2008 at 11:46 UTC

    I am a fan of prototypes. I know it is not recommended in Perl Best Practices because of the danger of someone pushing argments into an array and then passing the array.. e.g.

      sub prototyped( $ $ ) {
    print( "Arg 1: " . $_[0] . "\n" );
    print( "Arg 2: " . $_[1] . "\n" );
  }

  my @args = ( "first", "second" );
  prototyped( @args );

    [download]
    returns the following error:
      Not enough arguments for main::prototyped

    [download]

    However, as much as the prototype solution is broken for this situation, I'm still a fan of prototypes.

    Having prototypes has helped track down a bug in code used in production in a company whereby someone went in and modified the code adding a new parameter to each function. And then a minor bug slipped through whereby a call to one of the functions didn't provide enough arguments.

    Prototypes would have caught this in the compilation phase. In fact, by adding prototypes to all the functions we caught another instance whereby a function was being called with the wrong number of parameters..

[reply]
[d/l]
[select]

      When adding a new parameter to each call of a function, have the code behave one way with N args, and a different way with N+1. Ideally, by synthesising a default value for the missing parameter, and then going ahead and doing the same thing.

      There are many ways of working around this sort of codebase evolution. Having the code fail badly because one call was missed is just wrong. Perl is not C.

      As to the other point, yes it's true that prototypes catch things at the compilation phase, but it doesn't deal with passing a text string when a numeric was expected. For that, Params::Validate is a much more robust approach to ensure parameters are sane, especially in a large code base.

      • another intruder with the mooring in the heart of the Perl

[reply]

      Although I normally neither use nor need prototypes in Perl, I'd still love to see them being extended in such a way that you could make regular Perl functions behave like Perl builtins in every respect (think of overriding print, system, etc.).  I've come across some discussion along these lines on p5p (e.g. here), but I think things never went beyond just being discussed.

      (This is not my entire Perl 5 wishlist, btw, but the other items are still too vague / not thought-out enough yet, that I would dare to present them to this audience :)

[reply]
[d/l]
[select]
      vec() is prototyped. This pisses me off.
      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
[reply]

In Section Meditations