Re: IO::ALL (Was: check for errors on close())
Sam Vilain writes:
Smylers wrote:
Sam (or any other IO::All users reading this), what's your
experience of IO::All? How much effort has it saved you? Does it
make your code look
Hi Sam -- thanks for taking the time to answer.
I've only just begun to reap the benefits of it.
After how long of using it? Does that mean that initially you found it
more hassle?
Now, it seems that the built-in ways of doing these things are just
too awkward.
That strengthens my feeling that Ingy is on to something with his
shorter syntax, and that Perl 6 should benefit from many of his ideas.
Just this morning I cursed as I had to change;
While that strengthens my feeling that in Perl 5 the benefits of IO::All
typically aren't enough to make it worth having the module as a
dependency -- it isn't yet ubiquitous, and there are situations where
it's easier not to bother installing it and make do without instead.
my @mp3s = grep { -f } @ARGV, ($m3u?io($m3u):());
The behaviour of that line wasn't immediately apparent to me. Obviously
it does the same as the line below that you replaced it with, but even
after looking at the IO::All docs (well, the synopsis anyway -- they're
too long for me to be bothered to read all of them!) I can't work it
out. I'd've expected you to need to write something like:
my @mp3s = grep { -f } @ARGV, ($m3u?io($m3u)-chomp-slurp:());
to:
my @mp3s = grep { -f } @ARGV, ($m3u?(map{chomp;$_}`cat $m3u`):());
Hmmm, that does look rather messy (as well as having the platform-
dependent cat and the potentially insecure backticks). I'm not sure how
I'd've written it; perhaps like this:
use Path::Class qwfile;
# ...
push @ARGV, (file $m3u)-slurp if $m3u;
chomp @ARGV;
my @mp3s = grep { -f } @ARGV;
But the fact that Perl's built-in way of slurping isn't convenient shows
that there is a desire to use a module (whether IO::All, Path::Class, or
File::Slurp), and IO::All's chomp method looks nice -- that the built-in
chomp function doesn't return the chomped list makes my version above
more awkward than I'd like.
Perhaps Path::Class::File should steal IO::All's chomp method? (Or
perhaps that would start to bloat what is currently a very clean and
elegant suite of modules -- and if we keep doing things like that we'd
just end up turning Path::Class into IO::All, thereby proving that Ingy
was right in the first place.)
Clearly, there are two fairly opposite morals to read from that story.
Indeed!
And I think I've just about listed all that Spiffy does, so don't
worry about it! :)
Fair enough -- I wasn't really worrying about it, just a little curious.
Also, I'm open to being persuaded to start using it myself (but haven't
yet 'got it' sufficient to see what it'd do for me).
Smylers
--
May God bless us with enough foolishness to believe that we can make a
difference in this world, so that we can do what others claim cannot be done.
Re: IO::ALL (Was: check for errors on close())
Smylers wrote: I've only just begun to reap the benefits of it. After how long of using it? Does that mean that initially you found it more hassle? No, not at all. I've just only found myself using it twice so far. However, when I did I found it deliciously DWIMmy and extremely handy. eg, in http://svn.kwiki.org/ingy/Perldoc/lib/Perldoc/MugReader.pm I use it to accept a filehandle, string, filename, etc - whilst still being able to treat them all as if they were files, as well as knowing that now my module can accept URIs too! Now, it seems that the built-in ways of doing these things are just too awkward. That strengthens my feeling that Ingy is on to something with his shorter syntax, and that Perl 6 should benefit from many of his ideas. So come on over to p6l! :) Or, actually it's probably better to join in the pugs crowd and contribute an update to S29 based on IO::All and Path::Class. Perhaps there is even enough in Pugs to be able to start a basic implementation? At least the non-OO interface, anyway. Sam.
Re: IO::ALL (Was: check for errors on close())
Sam Vilain writes: Eric Wilhelm wrote: Just spent way too much time trying to find a bug when it turns out that I just had a full disk. So, food for thought for today: close() does not always return true. close(FILE) or die file error: $!; You don't already check the return value of every system call? I don't. Too tedious? That, and it makes the code look messier than needs be; a lexical variable going out of scope is very clean. Just use IO::All. I've looked at IO::All a bit, but never actually tried it -- it looks sufficiently daunting that I've never put the effort in to learn it rather than using something I was already familiar with. Possibly, if it really is as easy to use as it claims, it just suffers from too much documentation. I'll consider it the next time I'm writing a script that does a lot of stuff with files, but if reading from one file once is the only IO a script does then this seems like a massive prerequiste to pull in: suddenly I've added a big prereq to a project, and confused other coders in the team who know Perl but don't know IO::All, just to write 2 lines of code instead of 3 -- that doesn't seem worth it. Normally I don't buy the but I don't want to use a non-standard module cos that adds dependencies argument, but in this case I think it makes a big difference. Some of the things Ingy's doing in IO::All do look to be more Perl-ish than the current built-in Perl ways of achieving them, and I think I read Larry saying he'll incorporate some of them in Perl 6, which would be mos welcome. Sam (or any other IO::All users reading this), what's your experience of IO::All? How much effort has it saved you? Does it make your code look too confusing for other coders (I'm thinking of the overloaded comparison operators being used for something other than comparison, for instance)? Have you ever found it to be 'too clever', automating something in an inappropriate way? And finally, an implementation question, which, while not strictly relevant to a user of IO::All, does seem on-topic for a module authors' mailing list: does the Spiffy thing make sense to you? (I get the feeling that there's something I'm missing, or that I'm not clever enough to understand it.) For comparision, I've recently started using Path::Class, which is an excellent module. This also adds a non-standard dependency to file-handling tasks that other coders on my team may not have met before, and it doesn't do anything that isn't possible with core modules. But it's sufficiently well focussed that I could grasp it in one go, and see clear benefits; it feels natural, with objects representing obvious things and having intuitive interfaces: my code is definitely cleaner for using it, and I'm not worried that my co-workers will have trouble with it. (Actually, possibly one of the reasons I'm liking using Path::Class is that while it theoretically is a better interface to using File::Spec, we weren't using File::Spec previously, but concatenating and interpolating strings, awkwardly and non-cross-platformily; so it's a definite improvement.) Smylers -- May God bless us with enough foolishness to believe that we can make a difference in this world, so that we can do what others claim cannot be done.
Re: IO::ALL (Was: check for errors on close())
* Smylers [EMAIL PROTECTED] [2005-04-24 13:55]:
Sam (or any other IO::All users reading this), what's your
experience of IO::All? How much effort has it saved you? Does
it make your code look too confusing for other coders (I'm
thinking of the overloaded comparison operators being used for
something other than comparison, for instance)? Have you ever
found it to be 'too clever', automating something in an
inappropriate way?
Im not an IO::All user; Im posting to empasize this plea for
comments. I havent taken to it for the exact reasons Smylers
mentioned: both its (arbitrary-feeling) overloaded semantics and
the use of Spiffy seem too hair-raising to seriously consider it.
I would be very interested to hear from someone who has actually
used it in a large codebase that gets pummelled day-in day-out.
How does it pan out in practice?
For comparision, I've recently started using Path::Class, which
is an excellent module.
Yep, that one rocks. :-) Reminds me I should go add a review on
CPAN Ratings
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
