Re^6: On Backwards Compatibility and Bareword Filehandles

allow the *foo{IO} slot to be removed from GV
No, it doesn't. You can't break every XS module that interacts with Perl file handles.

If XS modules depend on the *foo{IO} slot today, then how do they work with current indirect filehandles? Or are indirect filehandles actually glob references, even though they print as =IO?

It would cause the following to fail

You are correct; however, the simple case I was considering was more like:

open INPUT, '<', $file or die ...;
while (<INPUT>) {
  ...
}
close INPUT;
[download]

You said the goal was to avoid barewords.

If I said that then I was mistaken; the goal was to provide an alternative to the removal of features suggested in the original Perl 7 announcement that I found objectionable. The improvements to I/O handling envisioned are simplifications by making all filehandles indirect filehandles, while retaining at least some of the existing syntax.

Comment on Re^6: On Backwards Compatibility and Bareword Filehandles Select or Download Code

Replies are listed 'Best First'.
Re^7: On Backwards Compatibility and Bareword Filehandles by ikegami (Patriarch) on Jul 22, 2020 at 07:01 UTC
how do they work with current indirect filehandles? What's an "indirect filehandles"? You mean a lexical file handles (e.g. `open(my $fh, ...)`)? Perl usually accepts A reference to an IO object. A glob containing a reference to an IO object. A reference to a glob containing a reference to an IO object. A string naming a glob containing a reference to an IO object. `open(my $fh, ...)` creates the third one. Every XS module that deals with file handles should support this. The last is the least supported by XS functions, if at all. The first is probably the next-least supported. The very ability to have references to IO object is relatively recent. That said, I mispoke about the extent of the breakage of CPAN that only support this type of handle would cause. In fact, I really don't know how much of CPAN would break if you suddenly changes the primary way to pass file handles around. however, the simple case I was considering was more like: That's irrelevant. I never said it would never work. If I said that then I was mistaken This is what you said. Clear as mud, I know. But there's no mention of Perl 7. the goal was to provide an alternative to the removal of features suggested in the original Perl 7 announcement Well, that's not entirely true, right? We're specifically talking about the removal of barewords. Maybe you have other features in mind too, but they're not being discussed here. So, like I said, the problem you're trying to solve is a need to avoid barewords. So my comment stands. What I provided a few posts up solves the problem a lot more simply and cleanly.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^7: On Backwards Compatibility and Bareword Filehandles
by ikegami (Patriarch) on Jul 22, 2020 at 07:01 UTC

how do they work with current indirect filehandles?

What's an "indirect filehandles"? You mean a lexical file handles (e.g. open(my $fh, ...))?

Perl usually accepts

A reference to an IO object.
A glob containing a reference to an IO object.
A reference to a glob containing a reference to an IO object.
A string naming a glob containing a reference to an IO object.

open(my $fh, ...) creates the third one. Every XS module that deals with file handles should support this.

The last is the least supported by XS functions, if at all.

The first is probably the next-least supported. The very ability to have references to IO object is relatively recent. That said, I mispoke about the extent of the breakage of CPAN that only support this type of handle would cause. In fact, I really don't know how much of CPAN would break if you suddenly changes the primary way to pass file handles around.

however, the simple case I was considering was more like:

That's irrelevant. I never said it would never work.

If I said that then I was mistaken

This is what you said. Clear as mud, I know. But there's no mention of Perl 7.

the goal was to provide an alternative to the removal of features suggested in the original Perl 7 announcement

Well, that's not entirely true, right? We're specifically talking about the removal of barewords. Maybe you have other features in mind too, but they're not being discussed here. So, like I said, the problem you're trying to solve is a need to avoid barewords. So my comment stands. What I provided a few posts up solves the problem a lot more simply and cleanly.

[reply]
[d/l]
[select]