Kenneth Albanowski writes:
|
| On Sun, 29 Oct 1995, Charles Bailey wrote:
|
| Hash slots of anonymous typeglobs seems to be the best solution all
| around. This however means that raw FileHandles, using "bearword" syntax
| as they do, can't participate in this. The hash slot of "STDIN" is
| %STDIN. This isn't particularly good.
|
| I suppose we could move to additional members (perhaps even an HV*) in the
| PVIO, but it seems that user-level code can do everything we want for now.
Actually, this seems a good time to rephrase one of the concerns I've had with
the way the I/O debate is going. Specifically, I understand that we _can_ cook
up an OO interface to files solely using Perl-mode code. Similarly, we _can_
define IO object as anything that ISA FileHandle (or whatever). What worries
me is that this is, at best, quite inefficient. While there's a lot to be said
for the argument that we implement a system in Perl as a prototype, and go back
and reimplement in C when the interface is settled, that model doesn't
translate well to parts of Perl which are probable performance bottlenecks.
I/O is just such an instance. While the OO model based on a FileHandle class
provides nice features, I'm uneasy about making it the _only_ way to extend
I/O. Perl's OO facilities, being 99+% runtime, aren't all that efficient, and
I'm worried that we're going to get a nice interface at the price of crippling
performance. For instance, if we decide an I/O object simply ISA FileHandle,
since Perl has no facility for determining inheritance at compile time, _every_
_call_ to C<print> triggers an @ISA lookup on the handle. How well does
caching of @ISA work? Finally, if we do start working with a Perl prototype,
what's the likelihood that some clever modules are going to take advantage of
implementation-specific details, leaving us with compatibility problems when we
do try to reimplement the intrface in a more efficient manner?
I'm far from expert on the internals related to method calls; if I'm starting
at shadows, please let me know.
| Current thoughts on this involve using prototypes to let Perl
| automatically convert this:
|
| foo(FH,"abc");
|
| into this:
|
| foo(\*FH,"abc");
|
| If I can talk Larry into providing multiple prototype for a single
| function, then all the variants of CORE::open() could be directly supported.
Sounds reasonable.
| As for FileHandle semantics, my proferred opinion is that the mechanism
| you describe as "class ISA FileHandle" should be used -- anything that
| ISA FileHandle (directly or indirectly) is usable as such.
Hmm. Apart the performance concerns I mentioned above, this also implies
a working ISA function, so Perl-level code could determine whether an
object ISA FileHandle.
| Currently the built in IO functions seem to use something remeniscent of
| "don't bother", and therefor I like "class ISA FileHandle" because it's
| directly compatible, and is nicely OO.
I agree that the current behavior isn't great. The silver lining is that,
since nothing's happening now, pretty much anything is compatible.
| This does however miss the point that FileHandles are real internal types
| (PVIO). Unfortunately, Perl's OO doesn't line up with it's typing system,
| so it's unclear what a "unified" solution would look like.
|
| I am strongly _against_ ^FH notation, and would prefer FileHandles to be
| more OO, not less OO.
I'm not sure that we should go one way xor the other. As you mention,
typing and OO derivation in Perl are largely orthogonal. There are
aspects of I/O management which would benefit from both, especially
if tying were available to cross the boundary between the two in
some ways.
Frankly, one of the assertions I've least understood in this thread
is, "I like the OO model, therefore don't add an I/O type". It seems
there are advantages to both, and implementing either won't interfere
with the other, so I don't understand the conflict. As an I/O user,
I'd generally prefer to work with an OO calling interface; as an I/O
implementor, I'd prefer a type interface.
| > | 6. What is the _simplest_ way to get tie() functionallity working on
| > | filehandles, that requires the fewest changes to perlCORE?
| >
| > Hmm. How's this for a general description:
| > Decide on a way to identify an I/O handle, so we can tie to one. Add check for
| > package methods to CORE routines for <>, binmode, chmod, chown, close, fcntl,
| > file tests (stat), flock, getc, open (? - only if we allow ties by name),
| > print, printf, read, rename, seek, sysread, syswrite, tell, unlink, and write.
| > Socket methods are also a possibility. Other file-associated CORE routines
| > operate on names, except C<select>, which is so bound to C-style file
| > descriptors that I'm not sure whether or how it'd interact with tied objects.
| > Write a base package which supplies default methods, often in terms of other
| > methods, or just fatal stubs.
|
| My stated opinion on _this_ one is that tie() really shouldn't apply to
| FileHandles, and instead should be implicit: any object that ISA
| FileHandle will have methods named like "PRINT", "READ", and "TELL"
| invoked at the right times.
The effect of either is pretty much the same -- we still need to identify the
pp_* functions affected, and insert either checks for tiedness or @ISA
traversals. It's just a question of interface and efficiency, as far as
I can see.
| Once again, this is more OO and less "internal". If filehandles were
| given explicit names (^FH) then obviously a tie() style interface becomes
| possible.
|
| > | 7. Are there any other questions?
| >
| > 7.1 How do we identify an I/O value?
|
| Right now, I'm all for ignoring this one, and letting the OO method call
| syntax work out the details. (As per above.)
How should we handle I/O method calls on a non-I/O object? Should the C code
detect that it's not ISA FileHandle and produce an error, or will we
need UNIVERSAL methods for all I/O calls which simply die (bleah)?
| > 7.2 How do we alias an I/O value into a typeglob (pretty much falls out of the
| > answer to 7.1)?
|
| You mean put the PVIO part of a glob into an anonymous glob, without
| transferring the rest? Interesting idea. One of Larry's comments about a
| new "glob notation" seems appropriate here. Something like this:
|
| *a{filehandle} = *STDIN{filehandle};
|
| (Or something like that. Ideally, you get to use keys(), and in general
| treat a glob just like a hash. The fallout with regards to regularlizing
| access to symbol tables should be obvious.)
Sounds good to me, in a number of cases. If the internal type of an I/O
handle is a GV, there's a problem here, but if it's an XPVIO, we're fine.
| Hmm. For those that have read down this far, here's a question for you:
| If Perl got compiled regexps, what sort of object would you like to see
| them as? Entries into the symbol table (and thus with their own symbol
| like "$" or "@"), or as references to a Regexp object?
|
| If the former, then one might have code like this:
|
| ~a = /\S+/c; # ~a is the variable, /c means compile
|
| if( /~a/ ) {
| #...
| }
|
| If the latter:
|
| $a = /\S+/c;
|
| if( /$a/ ) {
| #...
| }
I'm in the (apparent) minority in favor of more line noise. :-)
I _like_ the principle that $a represents a simple scalar value (already
violated by references, I realize), rather than one of a series of
semantically different things, whose only shared characteristic is the
singular number. For example, if complied regexps are objects of
class Regexp, then the meaning of C</$a/> is ambiguous; one needs to know
where $a came from to know whether a it's providing a string pattern or
a compiled regexp. (BTW, we also need to sort out eventually how
/$a$b/ [ or /~a~b/, or /~a$b/] will work.)
This is just an issue of aesthetics, though; I can certainly live with
whatever emerges.
| Next question: is such behaviour a good idea? For hashes, the answer seems
| to be "yes", because that way you can attach, disconnect, and reconnect
| hashs from various databases completely behind the back of some code.
|
| For FileHandles, since the handle is referring to some outside unit
| (perhaps a disk file, or a pipe, or a socket) it seems pretty clear that
| changing behaviour (or at least changing tie()'s) in mid-steam is _not_
| what we want. Or am I wrong here? What if the tie() was simply to install
| a "tee connection" into the filehandle, so a debugging trace could be
| made?
This ability would be useful for logging, vetting I/O, fallbacks, etc.
It also allows one to tie several (possibly localized) handles to the
same object, with the object's class methods tracking common state.
| For Regexps, I have absolutely no idea how this would even be used in the
| first place, so I can't offer much comment.
My guess is that this would provide the hook for such extensions as
inexact matching, gapped matching, weighted matching, constrained
substitition, etc. In other words, the tie doesn't affect the regexp
itself (unlike tied vars), but affects the actions in which the object
participates as a static value. Similar circumstances apply to I/O
handles and formats, from what I can see.
Regards,
Charles Bailey bailey@genetics.upenn.edu