> If not, you can always C<opendir 'C:/Windows/System'>.
Not under the RFC! :-) It calls for removal of opendir and lots of other
functions as being deletable because the new open can handle
directories, system calls, and so on.
In another email you asked:
> Why not extend C<open> to be able to take other things besides
> strings of text?
Registering a custom handler has this capability. For example:
use handler 'myhttp' => MyCustomMod; # upcoming syntax
open myhttp $packed_binary_data;
Otherwise, how could you tell what to do with it if you just said:
open $packed_binary_data;
Either open() gets way too big too quickly, with too many special cases,
or you just say "well, it can't handle this", which is a big loss.
Please understand one thing, I like the idea of being able to say:
open "http://www.yahoo.com";
I think it's cool. However, what I'm driving for with the RFC is a
stable, consistent interface, which is what I believe something as
critical as open() needs. I think the RFC should reflect this. If we
want to put true URI support in Perl, we can do that separately. Just
remember, there's no way to tell these two apart:
# File or directory?
open "file:///etc";
open "file:///etc/motd";
And with opendir gone, you have to be able to:
# Now we know
open dir "/etc";
open "/etc/motd";
-Nate
