Re: Should a dirhandle be a filehandle-like iterator?

2007-04-15 Thread John Macdonald
On Fri, Apr 13, 2007 at 08:14:42PM -0700, Geoffrey Broadwell wrote:
 [...] -- so non-dwimmy open
 variants are a good idea to keep around.
 
 This could be as simple as 'open(:!dwim)' I guess, or whatever the
 negated boolean adverb syntax is these days 

open(:file), open(:dir), open(:url), ... could be the non-dwimmy
versions.  If you don't specify an explicit non-dwimmy base
variant, the dwim magic makes a (preferrably appropriate) choice.

-- 


Re: Should a dirhandle be a filehandle-like iterator?

2007-04-15 Thread Larry Wall
On Sun, Apr 15, 2007 at 01:16:32PM -0400, John Macdonald wrote:
: On Fri, Apr 13, 2007 at 08:14:42PM -0700, Geoffrey Broadwell wrote:
:  [...] -- so non-dwimmy open
:  variants are a good idea to keep around.
:  
:  This could be as simple as 'open(:!dwim)' I guess, or whatever the
:  negated boolean adverb syntax is these days 
: 
: open(:file), open(:dir), open(:url), ... could be the non-dwimmy
: versions.  If you don't specify an explicit non-dwimmy base
: variant, the dwim magic makes a (preferrably appropriate) choice.

I suspect that since we have a type system now we should probably use it
for the non-dwimmy versions.

my $io = IO::File.open($str)
my $io = IO::Pipe.open($str)
my $io = IO::Socket.open($str)
my $io = IO::Dir.open($str)
my $io = IO::URI.open($str)

etc.  And of course different kinds of objects can have different
defaults.  I'd guess the default for directories is to take a snapshot
and sort the entries, for instance.  Certainly the open is the only
place we have to distinguish the type, and $io.close will close
any of them.

To me the interesting question is, when do we assume that a string
is a filename or uri?  I can argue that for historical and security
reasons bare open() should always assume the provided string is a
normal filename.  However, given that the existence of feed operators
removes most of my objections to Ingy's io() interface, we could make
that default to uri processing:

io('http://www.wall.org/~larry') == my @homepage;

Though we have a bit of a semantic problem insofar as

@source == io('file:foo')

is going to want to supply more arguments to io() rather than send
the feed to some method of the IO object, unless io() is some kind of
a context-sensitive macro, or at least has a signature that doesn't
allow slurpies.  And currently feed ops are considered statement
terminators, which makes it odd to think about overloading them.
More of a problem is that multiple dispatch based on argument type
depends on eager evaluation of dynamic types, while feeds are basically
lazy.  We don't know how hard to call io() without recognizing it
as special, or specifying the actual method:

@source == io('file:foo').print

Maybe that's good enough, but it seems like we could do a little
better.  Hmm, type coercions tend to be unary, or at least not
listy, so maybe we can just recognize types as returning source
and sink objects, which feeds automatically call with an appropriate
variadic method (.lines, .print, .tap) depending on pointiness:

IO('http://www.wall.org/~larry') == my @homepage;  # implicit .lines
@source == IO('file:foo')  # implicit .print
@source == IO($debuglog) == @sink # implicit .tap

Larry