This is PerlMonks "Mobile"

Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  


in reply to Introspecting function signatures

The general feeling was that the signature is an internal implementation detail of the subroutine, and that things outside of a subroutine shouldn't be relying on the ability to inspect it. For example, a sub that's part of a documented API in a CPAN module might, in a new release, switch back from using a signature to "manually" processing @_, because it turns out to be more convenient for achieving some new functionality added to to sub.

Introspection of the initial opcodes in a sub is fragile, and might break in new releases of perl. It won't work at all prior to 5.26, which introduced the argcheck/argelem/argdefelem ops, and the structure of the optree changed in 5.30. And (assuming I get my perl core mojo back at some point), there will be large changes happening to signatures in the future, reflected by big changes in the opcodes. And further changes when optimisation is added.

Dave.

Replies are listed 'Best First'.
Re^2: Introspecting function signatures
by szabgab (Priest) on Mar 05, 2021 at 21:29 UTC
    Thanks, this is what I was playing with: perltest. I would need the introspection of the function signatures to be able to provide dependency injection. Any suggestion in that direction? Specifically the run function. Would any of the modules that provide signature be a better idea?
[reply]
      I had a quick glance at that repo, and have no idea what it does apart from the fact that it's supposed to be similar to Pytest, about which I know nothing. So could you explain further the use case?

      Dave.

[reply]
        It is an experiment to write a module to allow you to write tests like this: 
        sub test_someting($tempdir) {
    ...
}

        [download]
        The test harness runs all the individual test_something functions. If the function has arguments that it will prepare the appropriate object and call the function passing those objects into the function. The example I created was injecting a $tempdir object, but, once the system is ready, you could write and register your own objects. In Pythest these are called fixtures, and they mostly act test fixtures. (In Pytest there are a few other ready-made such fixtures, for example one that captures stdout/stderr, and one that can mock methods, attributes, etc.)

        If you look at the modules in the t/ directory, those are all examples on how to use the module to write tests.

[reply]
[d/l]

In Section Seekers of Perl Wisdom