mgrimes.myopenid.com

• Website: mgrimes.myopenid.com/

Recent Actions

• Commented on Subroutine Signatures - my Plan (v.1)
  Thank you for working on this. The CPAN options are very good, but this really seems like it should be a core feature. What I would really like to see is support for named parameters as is implemented in MooseX::Method::Signatures....
• Commented on DateTime is annoying
  I usually try this first: DateTime->new( epoch => 1327673580 ); I would prefer it, since it eliminates the redundant "epoch" but keeps the named paramaters....

Comment Threads

• mpeters.myopenid.com commented on Subroutine Signatures - my Plan (v.1)

  Seems like a lot of the comments here are missing the fact that this is a simple first step that can be expanded later on. But things like method keywords, type constraints, etc need other features in Perl core to really work (like a MOP or actual types, etc).

  I like this idea because it starts simple but opens the gates for future improvements and optimizations without precluding them. And if we get this into core those other project won't have to reinvent the wheel to get signatures

• Salvador Fandiño commented on Subroutine Signatures - my Plan (v.1)

  You are doing language design, this is not something that can start simple and then grow. It just doesn't work that way.

  You have to plan the the new feature on the whole, consider all the things you want to support on the long run, and then, define an implementation plan that is where you can really start simple and then improve on it. Otherwise you will soon get caught on the backward compatibility trap.

  My impression is that this feature is being driven by implementation, you just saw a low hanging fruit and went for it.

• Aristotle commented on Subroutine Signatures - my Plan (v.1)

  This feature is driven by “this is the syntax every signature implementation on CPAN agrees on, and which every proposal on p5p (going back years and years) agrees on, so let’s leave out all of the features that nobody can agree on so we can finally have the features that nobody disagrees about, instead of never getting them because of all of the extra features people also want but can never agree on”.

  Hence to say “consider all the things you want to support on the long run” is to say “please waste a bunch of time so you can then fail …

• Reini Urban commented on Subroutine Signatures - my Plan (v.1)

  So the logic is: If someone disagrees with adding new syntax for signatures we are left in the stone age with this ridiculous oversimplifying proposal? Design by fear and ignorance, not even by committee?

  Signatures are the best chance to optimize perl function and method calls, since functions without sigs block all optimizations possibilities. There is really no chance to look into each function for argument assignments. Ditto for return types.

  Please talk at least to the perl6 people about the possibilities we have with proper sigs, if you do not understand me.

  We…

• Aristotle commented on Subroutine Signatures - my Plan (v.1)

  Is staying in the mesozoic era with nothing at all better than an insufficiently ambitious proposal? We could have had this much syntax 4 or 5 years ago if it wasn’t for the facts that a) people would never let a proposal stick to the basics (either the proposers wanted more, or other people wanted it to do more) and b) people could never agree on anything beyond the parts that this proposal specifies. Instead we continue to suffer my ($foo, $bar, $baz) = @_ for the foreseeable future. Is that really what we want, collectively?