And I - as a simple bystander - would read that as

if ( - e ($filename)) {
      ^
[download]

that is "the negative value returned by the function e with argument $filename".

#!usr/bin/perl -w
use strict;

my $file = 'C:\temp\test20.pl';

if ( -e  $file)
{
   print "$file EXISTS!\n";
}

print "$0 \n";

if ( - e $file)  #this does not work!
{
   print "$file WILD!\n";
}
__END__
Can't locate object method "e" via package "C:\temp\test20.pl" 
  (perhaps you forgot to load "C:\temp\test20.pl"?) 
  at C:\TEMP\test20.pl line 13.
C:\temp\test20.pl EXISTS!
C:\TEMP\test20.pl
[download]

I said that this was how I read that, and parens do matter here:

$ cat test.pl
#!/pro/bin/perl

use strict;
use warnings;

my $file = "/tmp/test20.pl";

-e   $file      and print "$file EXISTS!\n";
print "$0 \n";
- e  $file      and print "$file WILD!\n";
$ perl test.pl
test.pl
Can't call method "e" without a package or object reference at test.pl
+ line 10.
$
[download]

versus

$ cat test.pl
#!/pro/bin/perl

use strict;
use warnings;

my $file = "/tmp/test20.pl";

-e   $file      and print "$file EXISTS!\n";
print "$0 \n";
- e ($file)     and print "$file WILD!\n";
$ perl test.pl
test.pl
Undefined subroutine &main::e called at test.pl line 10.
[download]


Enjoy, Have FUN! H.Merijn

Even if you could, this is a bad idea.

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

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.

-QM
--
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