Just read that Data::Dumper dumps Perl data structures does this mean that code itself is a data structure.
Internally, code is held in data structures, but these are not standard Perl visible data structures like hashes or arrays, so you cannot easily manipulate them from Perl.
DDS just encapsulates B:;:Deparse to retrieve the source code.
can we modify this code properly and feed back to the Interpreter?
The return from DDS is a string. Perl can edit strings. Perl can also eval strings. So, you certainly could, edit the subroutine code and then eval (ie. reparse) the edited string to dynamically overlay the original subroutine.
Also, I believe that it is possible to use B::Deparse directly to modify the AST of a subroutine on the fly. I did look at this once (briefly) with the idea that it might be possible to extract the body of a subroutine and 'inline it', at the call sites to provide a macro facility. A nice idea, but fraught with complexities. It took very little reading before I gave up on the idea.
And remember, just because you can doesn't mean you should!.
I'm not shy of pushing at the boundaries, but my experience of using self-modifying code from way back when, is that it is a very bad idea. Imagine what happens when things go awry. Something failed, but you don't know what source code was being run when it went wrong. Was it that the editing process screwed up and produced valid, but unintended wrong code? Or Did it produce code as designed, but the design is wrong?
What happens if you have 2, 3 or half a dozen routines that optionally, dynamically self-modify, and interact to cause failures. But which combination of original and modified routines interact to cause that failure? It's a combinatorial nightmare.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|