Daniel Ruoso wrote:
Maybe I'm thinking sideways again, but I haven't thought of "open" as
being a method of any IO object, because usually "open" is the thing
that gets you an IO Object.
I'd expect the plain "open" to be really a sub (maybe a "is export"
method in the generic IO role), that does whatever it needs to do to
provide you an IO object, including composing the roles according to the
features it supports.
An important concept of testability is to decouple the use of objects
from their creation. Global factory functions make testing harder. That
said, in perl we can always override them, which would provide the
necessary seam.
One way of thinking about open is that it is a method on a file system
object (or, more generally, on an IO server role):
$fh = $*os.open($filename, :rw);
$fh = $internet.open($url, :ro);
...
Admittedly, that approach would tend to lead Perl down the road of Java,
so it's probably good to have a global sub to hide the underlying details.
It might seem even better be to introduce an object that represents the
concept of an openable thing:
$file = $file_system.find($filename);
$fh = $file.open(:rw);
However, file systems are very OS-dependent, so it is generally
counterproductive to attempt to build a data structure that shadows a
filesystem (e.g. what happens to $file if the underlying file is renamed?)
