Re: Previously unseen error in connection with -X functions

if they are not overridable then it returns undef - but then please note that the inverse implication does not hold.

yes, those with an undefined prototype are still overridable, but you can't make the replacement function behave like the original one in every way (due to parsing issues), for example exec/system's indirect object syntax.

BTW, I was once also in desperate need to override the filetest operators... so I'm pretty sure it cannot be achieved with the current implementation — but also see the patch mentioned in footnote 2 in the post I linked to.

Comment on Re: Previously unseen error in connection with -X functions Select or Download Code

Replies are listed 'Best First'.
Re^2: Previously unseen error in connection with -X functions by blazar (Canon) on Oct 31, 2008 at 12:37 UTC
BTW, I was once also in desperate need to override the filetest operators... so I'm pretty sure it cannot be achieved with the current implementation — but also see the patch mentioned in footnote 2 in the post I linked to. I personally believe that in that case one may use source filters as an extreme resource, but... they're generally deprecated and I presume even more so in the context of tests, which is most probably the one in which need of overriding and mocking functions is arising... (Was it yours too?) `--` If you can't understand the incipit, then please check the IPB Campaign.	[reply] [d/l]
Re^3: Previously unseen error in connection with -X functions by almut (Canon) on Oct 31, 2008 at 13:27 UTC
... (Was it yours too?) My need to override didn't arise in the context of testing, but with trying to write a 'compatibility module', which would allow to run ancient jperl v5.005 code in a recent version of Perl without modifications (large existing, tested codebase). Specifically, the problem was with trying to transparently convert japanese filenames between legacy and unicode encodings, because 5.005 did not support unicode, while modern versions of Perl cannot easily be configured to operate in the same old way that worked with jperl. Writing a source filter would have meant being able to reliably identify filename related code fragments in arbitrary Perl code... which I anticipated to be way too complex to get working in the time frame alotted to the project. (For anyone interested, I eventually decided to take the easiest route of utilising the deprecated USING_WIDE win32-perl macro (no longer available in Perl 5.10), which works reasonably well — In other words, I'm hoping there won't be significant code rot in Perl 5.8.8 before I retire... ;)	[reply]