[.I'm hereby summarizing and pulling together my comments on FileHandle
stuff. I've decided that things are just to splintered right now to make
writing large chunks of code (IO::Handle, etc.) a good proposition.
This forms a Request For Discussion, a stopping point for me, until the
issue reaches some form of resolution. I realize that Perl 6 might be that
resolution. :-)]
I'm rapidly getting to be of two minds on this subject: the I/O "SFIO
discipline" style, where behaviours can be stacked onto a handle, has
efficiency and simplicity going for it. The OO approach might be more
flexible.
The problem, as I see it, is that Perl will definitely need to support the
following techniques at some point in the future:
1. A "tied" file handle, without a real underlying handle:
OpenCurses(FH);
print FH "Abc";
ioctl FH, ATTRON, "bold"; # For lack of a better OOB call
close FH;
2. A tied handle with behaviour added to the standard set:
UUOpen(FH,">>foo.uue");
print FH "Now is the time...\n";
close FH;
If we go the OO route, then these will also need to be supported:
3. Provide custom "methods", and allow capture of standard methods:
SomeOOOpen(FH,">foo");
print FH "abc";
boogle FH 12;
gentlyclose FH;
4. Allow OO calling notation:
$a = new SomeOO ">foo";
$a->print("abc");
$a->boogle(12);
$a->gentlyclose();
Considering that Perl already has the "FileHandle" class, and lets
instances of that class (or a derivative) be used as in #4, this seems to
be a count in favour of OO. But #3 isn't implemented right now, nor is #1
or #2.
So... Which of #1, #2, or #3 does someone want to implement first? #2
seems to consist of very minor changes to the core, perhaps as part of
installing SFIO. Specifically, each call to file I/O functions would need
to check for some "tied" marker, and arrange for the callback (perhaps a
method in a package) to be called.
#1 is a bit more complex then #2, as no underlying file handle exists. One
could always open ">/dev/null", but is this the right approach? This
style is rather similar to the current tie() approach.
#3 is a completely different set of work, and probably least efficient.
It is the most flexible, though, as it seems that #1 and #2 could be
implemented in user-level code in terms of #3.
Now, I haven't mentioned "^FH" at all, simply because it hasn't been
relevent. Bearword notation has been sufficient for the examples. The
problem with bearwords can be stated simply like thi:
sub foo {
local(*A);
open(A,">abc");
}
Considering the move away from local(), and to my(), and the low-level
nature of globs, this is a bit of an afront. Considering that with refs
globs can now go unused in user-level code, how are we supposed to
explain this bit of "elegance" in the language?
One proposal is to turn FileHandles into official "variables", with a
graspable presence, via the addition of a "^" symbol, used like this:
open(^A,"<foo");
sub bar {
my(^A);
open(^A,">abc");
print ^A "test";
}
One question immediately presents itself: what about formats, and
dirhandles, and maybe compiled regexps in the future. Do all of these get
their own special symbols?
On the other hand, with a slight shift, the above syntax falls directly
into the OO camp:
$A = OOopen("<foo");
sub bar {
my($A);
$A = OOopen(">abc");
print $A "test";
}
This implies that the behavior we want is easily available if we go with
OO capabilities.
At this point, we seem to reach two immediate courses of action:
A. Finish up OO, so that the standard file operations get patched through
as method calls, as in #3 This instantly gives us #1 and #2, as well,
though with less efficiency.
B. Install a simpler mechanism to support #2 and perhaps #1 at the STDIO
level. With a bit of user-level hackery, this will probably give up #3 as
well, but it won't be as efficient as it could be.
A separate goal is:
C. Make FileHandles a separate semantic type, so they can be manipulated
as such.
I guess the final question is: any takers?
--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
stuff. I've decided that things are just to splintered right now to make
writing large chunks of code (IO::Handle, etc.) a good proposition.
This forms a Request For Discussion, a stopping point for me, until the
issue reaches some form of resolution. I realize that Perl 6 might be that
resolution. :-)]
I'm rapidly getting to be of two minds on this subject: the I/O "SFIO
discipline" style, where behaviours can be stacked onto a handle, has
efficiency and simplicity going for it. The OO approach might be more
flexible.
The problem, as I see it, is that Perl will definitely need to support the
following techniques at some point in the future:
1. A "tied" file handle, without a real underlying handle:
OpenCurses(FH);
print FH "Abc";
ioctl FH, ATTRON, "bold"; # For lack of a better OOB call
close FH;
2. A tied handle with behaviour added to the standard set:
UUOpen(FH,">>foo.uue");
print FH "Now is the time...\n";
close FH;
If we go the OO route, then these will also need to be supported:
3. Provide custom "methods", and allow capture of standard methods:
SomeOOOpen(FH,">foo");
print FH "abc";
boogle FH 12;
gentlyclose FH;
4. Allow OO calling notation:
$a = new SomeOO ">foo";
$a->print("abc");
$a->boogle(12);
$a->gentlyclose();
Considering that Perl already has the "FileHandle" class, and lets
instances of that class (or a derivative) be used as in #4, this seems to
be a count in favour of OO. But #3 isn't implemented right now, nor is #1
or #2.
So... Which of #1, #2, or #3 does someone want to implement first? #2
seems to consist of very minor changes to the core, perhaps as part of
installing SFIO. Specifically, each call to file I/O functions would need
to check for some "tied" marker, and arrange for the callback (perhaps a
method in a package) to be called.
#1 is a bit more complex then #2, as no underlying file handle exists. One
could always open ">/dev/null", but is this the right approach? This
style is rather similar to the current tie() approach.
#3 is a completely different set of work, and probably least efficient.
It is the most flexible, though, as it seems that #1 and #2 could be
implemented in user-level code in terms of #3.
Now, I haven't mentioned "^FH" at all, simply because it hasn't been
relevent. Bearword notation has been sufficient for the examples. The
problem with bearwords can be stated simply like thi:
sub foo {
local(*A);
open(A,">abc");
}
Considering the move away from local(), and to my(), and the low-level
nature of globs, this is a bit of an afront. Considering that with refs
globs can now go unused in user-level code, how are we supposed to
explain this bit of "elegance" in the language?
One proposal is to turn FileHandles into official "variables", with a
graspable presence, via the addition of a "^" symbol, used like this:
open(^A,"<foo");
sub bar {
my(^A);
open(^A,">abc");
print ^A "test";
}
One question immediately presents itself: what about formats, and
dirhandles, and maybe compiled regexps in the future. Do all of these get
their own special symbols?
On the other hand, with a slight shift, the above syntax falls directly
into the OO camp:
$A = OOopen("<foo");
sub bar {
my($A);
$A = OOopen(">abc");
print $A "test";
}
This implies that the behavior we want is easily available if we go with
OO capabilities.
At this point, we seem to reach two immediate courses of action:
A. Finish up OO, so that the standard file operations get patched through
as method calls, as in #3 This instantly gives us #1 and #2, as well,
though with less efficiency.
B. Install a simpler mechanism to support #2 and perhaps #1 at the STDIO
level. With a bit of user-level hackery, this will probably give up #3 as
well, but it won't be as efficient as it could be.
A separate goal is:
C. Make FileHandles a separate semantic type, so they can be manipulated
as such.
I guess the final question is: any takers?
--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)