in reply to Re: Is there any way to override "file test operator"?
in thread Is there any way to override "file test operator"?

Why can't the OP decide to make a smarter file test operator? Maybe instrument it, or log something, or count gumdrops? Or maybe he has a new file system idea, where there are virtual files, and they only show up with special juju magic? Or an evil twin has renamed some files with a specific pattern, and the code needs to test for both possibilities?

Sure, outside of that, it's probably not a good idea.

Quantum Mechanics: The dreams stuff is made of

  • Comment on Re^2: Is there any way to override "file test operator"?

Replies are listed 'Best First'.
Re^3: Is there any way to override "file test operator"?
by Marshall (Canon) on Mar 21, 2018 at 03:37 UTC
    I read back through this thread. Now that I see it again, the question appears to be "how can I make new file test operator?".
    I don't know how to do that.

    Overriding an existing file operator (like: -e $filename) is very bad idea. I stick to that opinion. The issue is when I see a line like that in some huge amount of code, I expect -e to do what it normally does without having to read any previous code that redefined that operation. And BTW, I don't know how to redefine -e either.

    In this case, I would make a subroutine that did the desired test and use that. In terms of execution efficiency, I see no difference. In terms of source code, there would be a huge increase in clarity.

      The benefit of overloading it, is that existing code "does the right thing", given whatever the new underlying context is, everyone can use the old idioms, even though they aren't quite the same.

      In fact, a good overload would not lose functionality on normal arguments. For instance, what if someone wanted to instrument logging by absolute filename, to collect statistics? Extending -e to do this would be easier than replacing every file test operator call everywhere, including external packages.

      For these kinds of questions, it's better if we get a real sense of the OP's ultimate goal and purpose, before declaring "that's a bad idea" just because it usually is.

      Quantum Mechanics: The dreams stuff is made of

      -e is broken on windows, it doesn't do unicode

      Win32::Unicode does do unicode , but it can't override -e

      So win32 people can't use -e on win32

      You're still not authority on what should or should not be done