> * 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(*).
> * 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.
But what do you mean you can't subclass them? And what pray tell is
a "first class object"? Please define "first class".
> * 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?
These:
open(STDOUT, ">filename")
open(STDOUT, ">&FH")
open(STDOUT, ">&=FH")
*STDOUT = *FH
are all *very* different beasties. What are you thinking that this
mythical assignment should be doing?
> * 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.
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?
Otherwise, there's no reason not to do:
local *FH;
return open(FH, "blah") && *FH;
or, for that matter, using lexical filehandles:
my $fh;
return open($fh, "blah") && $fh;
> * Do they even *get* garbage-collected they way real objects do???
Of course not. If you want to bless() them into something, though,
you may, and get a DESTROY() to trigger.
Wait: you mean "the way real variables do"? That is, when they go
out of use/scope? Of course they do, irrespective of which of the
two mechanisms I showed above
> * 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?
> * The "tiehandle" mechanism (blech).
Blech what?
>You can't even say that there's more typing involved to make
>the change, since both columns have the same number of characters,
>and the righthand-side is a lot easier to understand:
> print STDOUT "Hi"; print $STDOUT "Hi";
It is? What's easier to understand? I presume that STDOUT is
merely a class that has a print method--or, if it sucks to be you,
perhaps a function that returns a valid invocant. Think of STDOUT
to be a subclass of something, something, I suppose, like FileHandle.
>Scalars hold references to objects. Filehandles should, ultimately,
>be objects, as should directory handles.
I haven't yet seen anybody yet propose bifurcating {file,directory}handles.
This would certainly be nice.
--tom
