Polyfill for __SUB__ token - #46
Conversation
| require List::Util; # as it has the XS | ||
| List::Util->VERSION( $VERSION ); # Ensure we got the right XS version (RT#100863) | ||
|
|
||
| use constant CAN_SUB => $^V >= 5.016; |
There was a problem hiding this comment.
$^V is not available in 5.6 for example and stands for v5.x in later version
even if the compare is not incorrect for modern Perl version
you should use $]
|
as discussed on IRC this PR should probably be held until ROUTINE is made private (I think that is the side we fell to) and some documentation is added. |
atoomic
left a comment
atoomic
left a comment
There was a problem hiding this comment.
view comment about $] instead of $^V.
|
Is it as simple as changing the variable? Do I also have to change the comparison? |
|
No, it is already comparing against the right decimal number. |
|
This branch is very stale but locally a rebased version passes tests. Any opposition to me force-pushing the rebased version? |
|
I would say rebase && force push. The CI will confirm how it stands with the various Perl version |
|
OK so it fails on 5.6. Is that fixable? Is it allowable? |
|
@jberger the problem comes from So I came with a poor man alternate with an additional commit to provide it when missing, and it seems to work... view commit: view CI proof of concept: So cherry picking this commit to your branch should fix your concern. |
That's beyond my power to evaluate. @leonerd thoughts? |
5 participants
Per the discussion on https://rt.cpan.org/Public/Bug/Display.html?id=111466 this PR implements a polyfill for the
__SUB__token. The code is mostly lifted from Sub::Current (Rafael Garcia-Suarez). I did the porting and Aaron Crane helped with an issue I ran into.The one remaining question in my mind is if
ROUTINEshould be exported/exportable or not. The case for it is that it would allow a cautious user to always use the polyfill implementation rather than relying on__SUB__being the polyfill on old perl versions vs being the core token in newer versions. The case against is the added complexity of having two different names doing the ostensibly the same thing. Thoughts?The difference between
__SUB__andSub::Current::ROUTINEis the behavior inside the BEGIN/END/etc blocks. As a result this version ofROUTINEdiffers slightly from Sub::Current to match the behavior of__SUB__.