* Richard Hainsworth ([EMAIL PROTECTED]) [081126 08:21]:
> The S16: chown, chmod thread seems to be too unix-focussed.
>
> To be portable, the minimum assumptions need to be made about the
> environment in which a program operates. Alternatively, the software
> needs to be able to determine whether the environment it is operating in
> meets a minimum set of conditions.
> ...
> Thus I would suggest that the perl6 specifications should be written in
> an abstract way, one not related to a specific operating system and in a
> way that can be adapted by an implementor to specific systems.
I fully agree with you: the way the design is going is making the same
"mistakes" of Perl5 again. Where we were able to release the Perl5
syntax more and more when the design of Perl6 made more progress, so
should we do with the way we use modules. S16 is not doing that.
Also Rafael's suggestion to focus on POSIX is not the way a nice
interface should work. POSIX calls (and non-POSIX means) are
ways to implement the interface to the Operating System, which can
be different from the most practical interface on implementation level.
We should focus on OS abstraction.
For instance, if a file is represented in an object, then the most
friendly interface names would be like:
$file->owner($user);
my $user = $file->owner;
under the hood, we use chown and stat.
I really would like to see a "standard" object oriented view on the
system, which mainly autodetects the environment. I am really
fed-up using File::Spec and Path::Class explicitly all the time.
Also, I get data from a CD which was written case-insensitive and then
copied to my Linux box. It would be nice to be able to say: "treat this
directory case insensitive" (even when the implementation is slow)
Shared with Windows default behavioral interface.
So, I would like a radical change... trying to be as much general
(non UNIX specific) as possible:
(sorry, my Perl6 syntax is still very sloppy)
some global $*OS
# may be different per parallel instance of the program
# Maybe an OS function which returns $*OS
my $dir = $*OS.dir($*PROGRAM.arg[0]);
# above maybe hidden with a functional wrappers: dir $argv[0]
$dir.case_sensitive(0);
if $dir.entry('xyz').is_file {}
my $f = $dir.file('xyz');
$f.owner($*OS.user);
$*OS.system('ls | lpr');
print $*OS.family;
print $*OS.kernel_version;
my $pid = $*OS.process.label;
We should also be aware that we design Perl6 for parallelism. Do we
require all nodes to run the same OS (~version)?
Besides, I would really like to get a incremental growth path to do
things we cannot do yet. Some things are currently difficult to realize
under UNIX/Linux because there is not kernel interface defined for it.
For instance, you do not know in which character-set the filename is;
that is file-system dependent. So, we treat filenames as raw bytes.
This does cause dangers (a UTF-8 codepoint in the filename with a \x2F
('/') byte in it, for instance) But as long as the OS cannot provide
the user with this information, we should still give the author a way
to specify it.
$*OS.filesystem('/home', type => 'xfs', name_encoding => 'latin1'
, text_content_encoding => 'utf-8,bom', illegal_chars => "/\x0"
, case_sensitive => 1, max_path => 1024);
I have been working on such a module for Perl5 (which has a much wider
field than Path::Class) but (as many other of my projects) did not
complete it to a usable/publishable level (yet).
It is all NOT too difficult to implement (we do share this knowledge),
but the design of this needs to be free from historical mistakes. That's
a challenge.
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
