> say can't be prototyped because it supports say FH ...,
I can't follow, the fact that say is internally calling something like FH->print(@_,"\n") shouldn't have any consequence on the prototype.
Hmmm ...
I think what you mean is that this inhibits attempts to override say with another implementation, since it needs to act like an indirect method call, but with prototype magic.
| [reply] [Watch: Dir/Any] [d/l] [select] |
the fact that say is internally calling something like FH->print(@_,"\n") shouldn't have any consequence on the prototype.
It doesn't. It's the syntax that can't be recreated with a prototype.
I think what you mean is that this inhibits attempts to override say with another implementation,
Not at all. That's what the comment to which I replied said.
I pointed out that's not necessarily relevant since the OP didn't ask to replicate all of say's syntax, and irrelevant parts of say can't be recreated using prototypes.
It was a nitpick. It is, of course, entirely correct that the relevant behaviour of say can't be replicated with a prototype. It just can't be ascertained by the means used by the person to which I replied. This is all I said.
Seeking work! You can reach me at ikegami@adaelis.com
| [reply] [Watch: Dir/Any] [d/l] [select] |