Re^4: Prototypes required even after mocking a sub

I completely understand why the warning is emitted; I'm looking for answers as to how perl knows about the overwrite, considering the fact I've overwritten the symtab entry for it.

ps. This "dumb" website does links just fine.

Comment on Re^4: Prototypes required even after mocking a sub Download Code

Replies are listed 'Best First'.
Re^5: Prototypes required even after mocking a sub by Anonymous Monk on Sep 21, 2018 at 21:28 UTC
The post does not go through when I try to make that a link either using [] or html tags. I'm not sure I understand your question; Perl knows about it because you did it, and it checks for a mismatch in prototypes when that happens.	[reply]
Re^6: Prototypes required even after mocking a sub by stevieb (Canon) on Sep 21, 2018 at 21:35 UTC
"The post does not go through when I try to make that a link either using [] or html tags" Fair enough. We do have a subset and mix of things here. `[link_to_something\|words to describe]` is kind of backwards, but I digress. Getting to the point, I understand that perl knows about it, there's no question there. My question is how perl knows about the prototype(s), after I have effectively pissed all over the symtab entry for the sub. My question, more directly: Why and how does perl know that the sub I'm faking out (effectively), still keep reference to the prototypes that were involved in the subroutine I faked?	[reply] [d/l]
Re^7: Prototypes required even after mocking a sub by Anonymous Monk on Sep 21, 2018 at 21:43 UTC
It doesn't; as mentioned in the other thread it may compile against the original sub before it even gets to the prototype, as prototypes are used in the parsing phase. For example, the prototype ($) completely changes the meaning of this code: `my @results = (foo 3, 5);` If `foo` has a prototype of ($) then it will be executed as `my @results = (foo(3), 5);` rather than "slurping" up all the arguments available to it. This means that the parser constructs a completely different optree in this case. Overriding `foo` after that has been parsed doesn't change that.	[reply] [d/l] [select]