Re: What would you change?

[dragonchild]

• Move most of the built-in functions to libraries that are in the core. So, instead of log(), it would be Math::log() and use Math; would bring those functions in. This goes for about 70% of the functions. This makes the whole CORE:: and CORE::GLOBAL:: thing a bit easier to manage.
• Get rid of prototypes and find a real way to pass an array as an array to a function. The only suggestion I have is calling signatures.
• @ISA is a hack, as is UNIVERSAL::. All OO should be left for a module. The only good thing is bless().

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.

[monarch]

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 );

returns the following error:

  Not enough arguments for main::prototyped

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..

[grinder]

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.

[almut]

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 :)

[dragonchild]

vec() is prototyped. This pisses me off.

[BrowserUk]

I just sat and starred at the prototype of vec and tried to understand how it is a limitation?