in reply to open() enhancements

This convention of using a string to specify not only the file to open, but the how you want it open is thankfully on the way out. Here's an example where there's no string interpolation required to simply open a file:
open($foo, '<', $foo_file);
Throwing in extra syntax could start a sort of file-handle mini-language. Anything that makes Perl look more like line-noise is probably a bad idea.

For any odd parameters, maybe something like DBI, such as in this hypothetical example:
open($foo, '<', $foo_file, { sequential => 1 });
This could even be used to cram in permission bits, temporary flags, or what have you.

Replies are listed 'Best First'.
Re: Re: open() enhancements
by John M. Dlugosz (Monsignor) on Aug 22, 2002 at 23:40 UTC
    Two-arg open considered dangerous; syntax on the way out; etc.

    I've also read in Perl books how great it is, so that a script that takes a "file name" argument can actually do all that stuff.

    I do like the 4th argument as a hash. There can be universal "well known" names, and OS or FS specific flags that are only respected if applicable, such as { WIN32::tempfile => 1 } which would use the native temp file flag which may be somewhat different in meaning from a Linux temp file flag, etc. That is, by using a namespace-like syntax, flags can keep out of each other's way and not pollute the option space.

[reply]
[d/l]
      I've also read in Perl books how great it is, so that a script that takes a "file name" argument can actually do all that stuff.
      The two don't really relate that strongly... For security's sake you need to parse and verify the filename param to the script before handing it to open anyway. A design making it easy to pass unverified user input to potentially destructive syscalls is just inviting trouble.

      But then, I think we agree for the most part. We both seem to like the 4th argument hash idea. ;-)

      -Blake

[reply]
[d/l]
        So, who do we lobby about it?
[reply]

In Section Meditations