in reply to (Some) inconsistencies with IO built-ins, their documentation and filehandle names ("symbolic references")

I remember digging into it myself and becoming more and more confused in the past...

Maybe some historical background is helpful.

IIRC were lexical filehandles (with private variables and strict) only introduced with Perl5 (not even the first versions)

They are held in one of the 6 slots of a typeglob and were referenced by a uppercase bare word like "FH" named like the glob.

So writing FH meant using *FH{IO} like calling a sub "func()" meant using *func{CODE}->(). °

In order to be able to pass a filehandle as argument to a sub, you had to write *FH.

With Perl 5 came the need for lexical my $fh and avoiding typeglobs altogether while staying backwards compatible.

Now that's how the mess with alternative syntax started, and the docs retain a lot of old wording.

Ikegami already listed various different possibilities to denote a filehandle.

DISCLAIMER:

That's what I understood in the last 10 years lurking here in the monastery, I never coded Perl 4, so some details may be wrong.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

°) I think even this hash-like syntax to address slots in a glob didn't exist back then...

  • Comment on Re: (Some) inconsistencies with IO built-ins, their documentation and filehandle names ("symbolic references")
  • Download Code

Replies are listed 'Best First'.
Re^2: (Some) inconsistencies with IO built-ins, their documentation and filehandle names ("symbolic references")
by vr (Curate) on Jun 10, 2020 at 09:39 UTC

    Thank you for answers, ikegami and LanX, I understand the situation is pre-history heritage. Just curious, how it came that only open, opendir, print, printf actively object against "symbolic references" under use strict, in these Modern Perl times :). Even if it's too low priority to fix code, maybe stream-lining documentation would be not too much work -- now, where it's clearly stated strings are OK as indirection mechanism, the tone seems neutral or passively-encouraging :). Otherwise, to add to confusion, some built-ins (-X, etc.) accept both filehandles and strings (scalars/expressions), but here strings are filenames. Further curiosity, why all other /.*dir/ built-ins didn't possess indirection ability, in pre-history.

[reply]
[d/l]
[select]
      I can't tell much about implementation or API, cause it's very complicated.

      You might want to discuss this on P5P.

      Otherwise ... in order to have deeper insight and better feedback here, could you please provide a list of hands on examples of what you see and what you want?

      > Even if it's too low priority to fix code, maybe stream-lining documentation would be not too much work

      Well I think you are always welcome to provide patches to perldoc.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

[reply]
        You might want to discuss this on P5P

        Could you elaborate on that ?
        To me, "P5P" means the perl5-porters mailing list, but having been subscribed there for a number of years, I can report that virtually nothing of any significance now happens there.
        Every now and then, Steve Hay or SawyerX will announce a new stable release of perl, or someone will announce a new release of bleadperl, or Tony Cooke or David Mitchell will report on what they've been doing (and someone will probably respond by thanking them for doing what they're being paid to do).
        Or someone might come up with some rubbish half-arsed idea.

        But, IME, that list is currently the last place you want to go if you wish to initiate some sort of meaningful conversation.

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom