Eryq wrote:
> 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 filehandl
Let's table this discussion, please. There are two different concerns
here:
1. IO::Handle et al *are* too damn big and slow.
2. Bareword filehandles *are* a pain to deal with.
Perl 5.6 already has a lot of this solved by allowing lexically-scoped
variables to hold filehandles. We should
I will never, ever, ever possibly begin to process all this mail.
It's completely impossible. I have three days before I leave the
country for three weeks, and nothing is done. Therefore, my answer
to you will be short and underdone. One can type on p6 lists *all*
day and get no nearer to closu
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 issu
Tom Christiansen wrote:
>
> >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.
If I'm understanding what you mean, I bel
>This is already allowed. It's called "passing in a bareword".
>And barewords are just strings. Are you proposing
>that "a bareword should now mean a filehandle", so that
> copydata(STDIN, STDOUT);
>means something different from
> copydata('STDIN', 'STDOUT');
>or
> cop
>> What if it's an anonymous stream?
>How do you open an anonymous stream?
Me? This way:
local(*HITHER, *THITHER);
pipe(HITHER, THITHER) ..
or, I suppose,
my($hither, $thither);
pipe($hither, $thither) ..
or even
pipe(my $hither, $thither) ..
Why, how d
>So why not allow undecorated variables a larger existence?
We already have them. You can use a sub name or a package name
where you mean an "undecorated variable". In fact, you can have
things generate/populate new subs or packages as you like it.
use Funny_Business;
frob Funny "
> * 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
"David L. Nicol" wrote:
> >
> >1. You must use globs to pass them in and out of functions
>
> This could be resolved by allowing undecorated types to be passed
This is already allowed. It's called "passing in a bareword".
And barewords are just strings. Are you proposing
that "a barewor
"David L. Nicol" wrote:
> Nathan Wiger wrote:
> >3. There's no way to have them interpolated in strings into
> > something potentially useful.
>
> The string value of a file handle. Hmm. Is it's internal file
> descriptor number?
Umm... that's the numeric value of a file handle, ri
Nathan Wiger wrote:
(in response to an assertion of preference for undecorated filehandles)
> Well, I think you might be overlooking a couple of important things
> about filehandles. First, having them NOT be scalars caused many
> problems:
>
>1. You must use globs to pass them in and out o
"David L. Nicol" wrote:
> File handles work perfectly well
> right now as undecorated terms with well defined characteristics
Perfectly well?
* Have to use ugly globref syntax to pass them around reliably.
* Not first-class objects, so you can't subclass them.
* Special
"David L. Nicol" wrote:
>
> I don't know how large a point of view I represent, but I do not agree that
> all data should be decorated like scalars.
Well, I think you might be overlooking a couple of important things
about filehandles. First, having them NOT be scalars caused many
problems:
> =head1 ABSTRACT
>
> Consensus has been reached that filehandles (currently
> barewords) will be revamped to become true $scalars, to
> make them consistent with other Perl variables.
>
> C, C, C, and C should follow suit and be
> renamed C<$STDIN>, C<$STDOUT>, C<$STDERR>, and C<$DATA>, becomi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 04 Aug 2000
Last-Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
16 matches
Mail list logo
