Tom Christiansen wrote:
>
> > * Have to use ugly globref syntax to pass them around reliably.
>
> No, you don't. You can use globs. But only if you don't have
> prototypes, like sub opt(*).
I would argue that many Perlers don't use prototypes.
Whether they should or not is another issue, but prototypes
are optional, and I believe they aren't useful in "named argument"
cases like this anyway:
$foo->output(Verbose => 1,
Formatter => $fmt,
Output => \*MYFILE,
Errors => \*STDERR);
> > * Not first-class objects, so you can't subclass them.
>
> That's not a good argument. I can't subclass a number, either, nor
> a function or format for that matter.
It is a good argument when you consider how useful it is to be
able to subclass an output handle. Look at all the IO:: classes;
if they weren't useful (at least, in the eyes of some people),
we wouldn't have them.
Subclassing is a means of extending or modifying the behavior
of an existing abstract data type in a simple, strightforward way.
It's well understood. If we want to support output-handles with
different kinds of behavior (and, as the author of IO::Scalar,
I think that we do :-) ), then I argue that we should do so in
an object-oriented fashion.
> But what do you mean you can't subclass them?
Here's an excerpt from the IO::Handle documentation:
BUGS
Due to backwards compatibility, all filehandles resemble
objects of class IO::Handle, or actually classes derived
from that class. They actually aren't. Which means you
can't derive your own class from IO::Handle and inherit
those methods.
Gosh darn it, what if I *want* to derive my own class from
IO::Handle and inherit those methods? And notice that Graham
is listing this incapability as a BUG. I agree with him.
> And what pray tell is
> a "first class object"? Please define "first class".
I would want filehandles to be governed by the same rules as
any user-defined object: e.g., I want to be able to
use method invocation in the same manner, I want to be able
to create subclasses, and I want to be able to inspect
instance variables.
In other words, I don't want sentences like that snippet from
IO::Handle above.
> > * Special syntax to reassign STDOUT, instead of just $STDOUT = $foo.
>
> What do you mean by "reassign to standard output"? Do you mean
> that file descriptor #1 should be pointing to a new place?
> What are you thinking that this
> mythical assignment should be doing?
The same as any conventional assignment: to replace the object
that represents the standard-output channel (*not* fd 1) with
one of my own choosing. So that if someone has provided a CPAN
module with this mythical Perl6 snippet:
sub printheader { print $STDOUT "Content-type: text/html\r\n\r\n"; }
I can replace $STDOUT with, say, an IO::Scalar which routes
all output to core:
$STDOUT = new IO::Scalar \$data;
printheader();
### the header is now in $data
> > * Stupid "gensym" tricks to create unique names.
>
> There is nothing "stupid" about using Symbol::gensym() to generate
> unique symbols. That is, after all, its purpose.
I didn't say that gensym() was stupid. I implied that this was a
bizzare way to create new filehandles. I much prefer:
$fh = new FileHandle;
because this is familiar turf: you can show this to any novice
developer with a smattering of OO, and even if they don't know
what FileHandle is, they have a pretty good idea that a new
instance of class FileHandle is being created and assigned
to $fh.
> However, why you are doing so for filehandles is unclear in the extreme.
> Do you *truly* need a new and unique name? I'd like to see such code.
> Why? For error reporting?
IO::Handle uses gensym in its new() methods. Is it, as you say,
"unclear in the exteme" why IO::Handle is doing so? It's clear
to me: in order for IO::Handle to create a brand-new object, it
must have a brand-new symbol because of Perl's underlying use
of strings as means of discriminating i/o channels.
And all that I am saying is that this syntactic complication,
this special case where "the filehandle name *is* the object",
should be gotten rid of. Unlike some other special Perl syntactic
constructs (e.g., regular expressions, "here-is" documents),
the current filehandle syntax does not add anything of value to the
language, and yet it has caused a lot of confusion when new Perlers
try to pass filehandles around between packages, and they don't
yet know about globs.
> > * STDOUT->flush barfs if you don't "use FileHandle" first; sheesh.
>
> Perl doesn't have built-in methods there: true. Perhaps you
> are proposing an implicit autoload?
Actually, I'm proposing:
$STDOUT->flush
with all that implies (if that means autoloading of IO::Handle,
then so be it).
>
> > * The "tiehandle" mechanism (blech).
>
> Blech what?
This is an aethetic difference between us, so it won't be
resolved, but I'll say only that I've regarded tie() as
being more intrusive than I like. I'd prefer it if
Perl worked as follows:
If I provide a class X with a PRINT() method, and do
no more than that, then I'd love it if instances of X
could automatically be used like this:
my $x = new X;
print $x "Hi there\n";
Anyway, I've said enough. Sorry if you've misconstrued it
as my "calling your baby ugly". We love Perl, we truly do.
We love it so much that we want it to be as easy as possible for
others to learn, so that they can love it, too.
> I haven't yet seen anybody yet propose bifurcating {file,directory}handles.
> This would certainly be nice.
You mean, like a handle with a built-in "tee" capability?
Eryq
