Perl Monk, Perl Meditation | |
PerlMonks |
Re: Recap: The Future of Perl 5 (backwards comaptibility, RFC)by LanX (Saint) |
on Aug 31, 2018 at 18:23 UTC ( [id://1221471]=note: print w/replies, xml ) | Need Help?? |
We can easily speculate about a new "sexy" syntax which "Easy things should be easy, and hard things should be possible"°. The crucial problem for the acceptance is backwards compatibility , both semantically and syntactically. Most of us are stuck with an older version of Perl before the team decides to upgrade, so it would be very important for acceptance if the "sexy" syntax could already be run there. NB: It doesn't need to be fast ... just complete. referring to a new version for speed could be a good incentive and marketing. let me suggest something, would this syntax be acceptable?
please note that use class Point could be shortend to class Point with Keyword::Simple for Perl > 5.13 The whole mechanism would work with a safe source filter˛ which just injects some boilerplate OO package header at the _beginning_, and a callback which is triggered at the end of scope.* The callback would inspect the STASH of the package and use PadWalker to identify instance variables. The indentified subs (like "inverted") would be patched and wrapped with initialising code mapping the first argument to $self ( a closure var from the boilerplate). Wrapper would look like something like
( I deliberate used references for instance vars, to have a visual clue) This and the use of attributes for more "exotic" features would allow us to stay comaptible to
Of course the "real" implementation would use dedicated opcodes and ammend the parser, hence be mmore performand. Comments?
Cheers Rolf
°) didn't that use to be Perl's motto? (update: yep) *) NB you don't need the block if there is only one class per file. ˛) safe because the source filter is just injecting code at the beginning and doesn't attempt to parse Perl.
In Section
Meditations
|
|