Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sub Signatures: Next Steps

659 views

Published on

YAPC::NA 2014 talk slides for Sub Signatures: Next Steps

Published in: Software, Technology, Art & Photos
  • Be the first to comment

  • Be the first to like this

Sub Signatures: Next Steps

  1. 1. Sub Signatures Next Steps Peter Martini github.com/PeterMartini PeterCMartini@GMail.com @PeterCMartini
  2. 2. We did it!
  3. 3. use feature 'signatures' now available in 5.20 Thanks @rjbs and Zefram
  4. 4. 1) Review last year's talk 2) What's in 5.20 3) What's contentious in 5.20 4) Potential enhancements for 5.22 5) Long term enhancements
  5. 5. Goals from last year's talk: Add API for get/fetch – X Add API for parsing – X Add a new module – ✓ Update CPAN signatures – X Performance boost – X
  6. 6. What's in 5.20?
  7. 7. All of the following assumes: use feature 'signatures'; no warnings 'experimental';
  8. 8. Named Parameters sub foo($bar, $baz)
  9. 9. Anonymous Parameters sub foo($, $baz)
  10. 10. Default Values my $n = 1; sub update($rec, $id = $n++)
  11. 11. Default Values (but only for scalars) sub nope(@arr = (1,2)); # syntax error
  12. 12. Strict Checking sub twoargs($one, $two) {} twoargs(1); # dies
  13. 13. Strict Checking sub usedef($one, $two=2) {} usedef(1); # lives!
  14. 14. With Attributes: sub foo :prototype($) ($bar) {}
  15. 15. How it works:
  16. 16. Perl, while parsing, rewrites signatures into equivalent opcodes
  17. 17. perl -MO=Deparse -Mfeature=signatures -e 'sub foo($bar){}' The signatures feature is experimental at -e line 1. sub foo { use feature 'signatures'; die 'Too many arguments for subroutine' unless @_ <= 1; die 'Too few arguments for subroutine' unless @_ >= 1; my $bar = $_[0]; (); }
  18. 18. After parsing, there is no trace left of what the signature was
  19. 19. What's contentious in 5.20?
  20. 20. In 5.18 and before: sub CONSTANT(){ 5 } Replaced by a constant at runtime
  21. 21. In 5.20, it becomes: sub CONSTANT { use feature 'signatures'; die 'Too many arguments for subroutine' unless @_ <= 0; (); 5; }
  22. 22. sub foo : lvalue ($bar) {} # Legal sub foo : lvalue($bar) {} # Syntax error
  23. 23. sub foo($bar); # Syntax error
  24. 24. No path to making use feature 'signatures'; a default
  25. 25. This is why it's still experimental
  26. 26. Goals for 5.22:
  27. 27. Get past experimental!
  28. 28. Revisit signature placement
  29. 29. Right now we have: sub <name> <proto> <attr> And: sub <name> <attr> <sig>
  30. 30. Having the signature after the attributes can cause subtle bugs
  31. 31. Having the signature after the attributes makes coexistence of prototypes and signatures much harder
  32. 32. Especially problematic for sub CONSTANT() {}
  33. 33. Make signatures faster
  34. 34. signatures right now do no more than rewrite your code
  35. 35. Which means it is exactly as fast as doing it by hand
  36. 36. This does not have to be the case
  37. 37. Preserve the signature
  38. 38. Not just for aesthetics; preserving the signature allows sub CONSTANT(){} to work again
  39. 39. Among other optimizations
  40. 40. Tweak error handling
  41. 41. signatures right now injects a 'die' into the sub if the arguments don't match
  42. 42. Which means the error is reported in the sub, not the caller
  43. 43. This is fixable for 5.22
  44. 44. Possible enhancements for 5.22
  45. 45. A separate feature to have signatures imply prototypes
  46. 46. Having a compatibility mode for signatures would allow safely* turning it on by default
  47. 47. safely* - code that warned about illegal prototypes would now probably die; CPAN modules that hijack prototypes would have to be modified to turn off signatures
  48. 48. Allow signatures in sub declarations
  49. 49. Aside: signatures v. initialization block
  50. 50. Defaults in declarations is a sticky subject
  51. 51. # This is bad our $bar; sub foo($baz = $bar); … { my $bar = 5; sub foo($baz = $bar) {} }
  52. 52. # This isn't any better! sub foo($baz); … { my $bar = 5; sub foo($baz = $bar) {} }
  53. 53. # This one's sticky ... sub foo($); … { my $bar = 5; sub foo($baz = $bar) {} }
  54. 54. # Maybe this? sub foo($baz = ...); … { my $bar = 5; sub foo($baz = $bar) {} }
  55. 55. Fatalize redefinition
  56. 56. Not necessary, but enables optimizations
  57. 57. (sub redefinition already breaks prototypes)
  58. 58. Long term enhancements
  59. 59. Particularly things that can benefit from core
  60. 60. Readonly args sub foo($bar : ro)
  61. 61. Native types sub foo(int $a, num $b, str $c)
  62. 62. Package types sub foo(Some::Class $bar)
  63. 63. Calling parameters by name
  64. 64. sub foo (-bar, -baz = 2) {} foo(-bar => 1); This could be made as fast as simple assignment
  65. 65. Aliasing
  66. 66. sub foo($bar : alias) { $bar = “New”; } my $var = “Old”; foo($var); # $var is now “New”
  67. 67. Implicit $self (method keyword? There's a method attribute already)
  68. 68. Custom handler for sub redefinition
  69. 69. Which would allow multi methods on CPAN
  70. 70. Retrieve signature as a core function
  71. 71. API to override signature parsing
  72. 72. The goal is to let you make promises to Perl, which Perl can enforce for your sanity and its speed
  73. 73. Questions?
  74. 74. Thank you for coming

×