I want to re-iterate, briefly, the points that Charles Bailey has made
regarding ^HANDLE.
Tom dislikes ^HANDLE on aesthetic and philosophical grounds. I can
respect that position. However, I find Charles' arguments convicing.
Larry, especially: Please weigh in.
According to Charles Bailey:
> I agree that we ought to be moving towards using objects for new development,
> but I also think that we need to consider the aspects of stream handling that
> we won't get with a File(Handle)? class, but will get with syntax:
>
> - lexical congruence with the current use of streams by 'privileged'
> CORE routines. In other words, a call to vanilla C<open> and to
> someone's replacement for C<open> or a distinct routine with a
> similar action will look the same. [...]
>
> - Designation of "I/Oness" to CORE I/O routines (and ability
> to test for it directly). We really ought to have a way to
> say "one can read from this object, or write to it, etc.",
> both for use by internal routines like C<print>, and to
> allow us to determine this. We can't do this just by using
> blessed FileHandle objects, since we'll want over time to
> create a number of different classes which implement
> functionality over and above vanilla C<open>. [...]
>
> - Implementation of tied file handles. [...]
>
> | Charles's point that it would nice to have lexical FileHandles is valid,
> | but he points out himself that lexical references are a workround.
>
> True. My feeling here, like Chip Salzenburg's, is that it works,
> but it's clunky, especially since it will coexist with a syntax
> that does explicitly specify file handles, but just isn't available
> to other than some CORE routines.
--
Chip Salzenberg, aka <chs@nando.net>
"Hey, it's the Miss Alternate Universe Pageant!"
-- Crow T. Robot, MST3K: "Stranded In Space"
regarding ^HANDLE.
Tom dislikes ^HANDLE on aesthetic and philosophical grounds. I can
respect that position. However, I find Charles' arguments convicing.
Larry, especially: Please weigh in.
According to Charles Bailey:
> I agree that we ought to be moving towards using objects for new development,
> but I also think that we need to consider the aspects of stream handling that
> we won't get with a File(Handle)? class, but will get with syntax:
>
> - lexical congruence with the current use of streams by 'privileged'
> CORE routines. In other words, a call to vanilla C<open> and to
> someone's replacement for C<open> or a distinct routine with a
> similar action will look the same. [...]
>
> - Designation of "I/Oness" to CORE I/O routines (and ability
> to test for it directly). We really ought to have a way to
> say "one can read from this object, or write to it, etc.",
> both for use by internal routines like C<print>, and to
> allow us to determine this. We can't do this just by using
> blessed FileHandle objects, since we'll want over time to
> create a number of different classes which implement
> functionality over and above vanilla C<open>. [...]
>
> - Implementation of tied file handles. [...]
>
> | Charles's point that it would nice to have lexical FileHandles is valid,
> | but he points out himself that lexical references are a workround.
>
> True. My feeling here, like Chip Salzenburg's, is that it works,
> but it's clunky, especially since it will coexist with a syntax
> that does explicitly specify file handles, but just isn't available
> to other than some CORE routines.
--
Chip Salzenberg, aka <chs@nando.net>
"Hey, it's the Miss Alternate Universe Pageant!"
-- Crow T. Robot, MST3K: "Stranded In Space"