On Mon, Dec 15, 2008 at 10:43 AM, Richard Hainsworth
<rich...@rusrating.ru>wrote:
> a) I am fed up with writing something like
>
> open(FP, ">${fname}_out.txt") or die "Cant open ${fname}_out.txt for
> writing\n";
>
> The complex definition of the filename is only to show that it has to be
> restated identically twice.
>
> Since the error code I write (die "blaa") is always the same, surely it can
> be made into a default that reports on what caused the die and hidden away
> as a default pointer to code that can be overridden if the programmer wants
> to.
>
> b) Why do I have to 'open' anything? Surely when software first identifies
> a File object (eg., names it) that should be sufficient signal to do all the
> IO things. So, I would love to write
>
> my File $file .= new(:name<mydatafile.txt>);
>
> my File $output .=new(:name<myresults.txt>, :mode<write>);
>
You've essentially replaced the klunky mode parameters in perl5 (">file")
with a cleaner role constructor. I would argue that an autodie built-in
feature would be nice with perl but it may not be a good idea to always
force a die. Maybe it could be a feature/macro that could be turned on (like
'use autodie;').
> and then:
>
> while $file.read {…};
>
> or:
>
> say "Hello world" :to<$output>;
I usually do something more like:
@ARGV = ("file.txt");
@data = <>;
It's lazy and kinda cheating, but for small simple tasks, it gets the job
done. I'm not up to speed with the IO spec, but a sort of auto-slurp
functionality would be nice. Something to the effect:
@data = :slurp("mydatafile.txt");
That's just a crude example and possibly not even valid perl6, but it would
be nice to have a quick read-only file slurping functionality. This is
usually the first thing I hack into larger scripts so that I can forget
about doing IO (means to an end).
In fact, File::Slurp does this right now in perl5.
> c) I want the simplest file names for simple scripts. As Damian Conway has
> pointed out, naming a resource is a can of worms. I work with Cyrillic texts
> and filenames and still have problems with the varieties of char sets.
> Unicode has done a lot, but humans just keep pushing the envelop of what is
> possible. I don't think there will ever be a resolution until humanity has a
> single language and single script.
>
> It seems far better to me for standard resource names to be constrained to
> the simplest possible for 'vanilla' perl scripts, but also to let the
> programmer access the underlying bit/byte string so they can do what they
> want if they understand the environment.
>
> The idea of 'stringification', that is providing to the programmer for use
> inside the program a predictable representation of a complex object, also
> seems to me to be something to exploit. In the case of a resource name, the
> one most easily available to the programmer would be a 'stringified' version
> of the underlying stream of bytes used by the operating system.
>
> Eg. if a File object located in some directory under some OS would have
> both $file.name as a unicode representation and a $file.underlying_name
> with some arbitrary sequence of bits with a semantics known only to the OS
> (and the perl implementation).
It would actually be nicer if I the filename defaulted to my platform and I
there were naming convention converters provided. I don't know how that
should look and it actually sounds like something that should probably be
provided by modules.
Some of what File::Spec provides now would be nice built in, but how much is
up for debate. I think File::Path::canonpath and File::Path::path would be
nice attributes to add to the File role.
Allowing access to the filter function (allowing a programmer the ability to
> override an attribute) could be quite useful. For example, suppose the role
> providing getline includes an attribute with default
>
> $.infilter = { s/\n// }; # a good implementation would have different rules
> for different OS's
>
> and this can be overridden with
>
> $.infilter = { .trans ( /\s+/ => ' ' ) }; # squash all white space to a
> single space
> or
> $.infilter = { s/\n//; split /\t/ };
I would imagine a filter role would be useful. If they're roles, it allows
people to build layers of functionality on them to do various different
kinds of filters, turn them on and off, etc. With filters as roles, I would
love to imagine something like this:
my File $fstab = new(:name</etc/fstab>, :filter<new WhitespaceTrim>)
Yet another crude example, but imagine once the whitespace cleaner above
trimmed things down, and output filter could then realign them. I see more
utility if the filter were a role than some $.infilter scalar that can be
clobbered by multi-threaded applications.
> Perhaps, too a module for a specific environment, eg., Windows, would
> provide the syntatic sugar that makes specifying a location look like
> specifying a directory natively, eg.
> use IO::Windows;
> my Location $x .= new(:OSpath<C:\\Documents\perldata\>);
> whilst for linux it would be
> use IO::Linux;
> my Location $x .=new(:OSpath</home/perldata/>);
This looks like a good start to the whole file path issue discussed above
but gets too OS specific. I think things like FUSE and Samba on linux could
throw a real curveball into that but I'm not sure how much latitude the
kernel gives file systems and userspace applications the power to change the
default naming scheme (i.e. if / can be changed to \).
-Jason "s1n" Switzer
