[PROPOSAL] File pmc, OS pmc, Path pmc and others
Alberto Simões
After some discussion on #parrot, and after Leo direct me to this link:
http://mail.python.org/pipermail/python-dev/2006-January/060026.html
Follows some discussion on File.pmc.
1) What it is now.
At the moment we have two OS dependent PMCs: OS and File.
OS includes stat, mkdir, remove, link, symlink, umask, chdir.
File includes is_dir, is_file, is_link, copy, rename
Both PMCs are static classes (no objects, just methods)
2) What it might be.
My first idea is to join both PMCs, and create a FileSystem PMC. The
main problem is its name. After looking to Python discussion, and
thinking a little on the PIR syntax, I would call it Path.
That way, we could have things like:
$P0 = new .Path("/foo/bar")
$P0.mkdir()
$P0.remove()
$P0.link("new/file") ## or $P0.link($P1) where $P1 is a Path
object, or both
$P0.symlink("new/file")
...
$P0.is_dir()
$P0.is_file()
$P0.copy("copy")
and so on.
I am not sure, but I think it would be also possible to:
$S0 = $P0 # get filename
$P0 = $S1 # change object... similar to 'new .Path($S1)'
If we want to mask dos/linux/mac, we can use
$P0 = new .Path("foo","bar")
so that Parrot uses the correct separator.
3) Implementation
Some discussion have taken place before regarding copy and rename
implementation. I think we can subclass this PMC for specific OSes, and
specific FileSystems if needed.
Cheers
ambs
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
Nicholas Clark
> 2) What it might be.
>
> My first idea is to join both PMCs, and create a FileSystem PMC. The
> main problem is its name. After looking to Python discussion, and
> thinking a little on the PIR syntax, I would call it Path.
> 3) Implementation
>
> Some discussion have taken place before regarding copy and rename
> implementation. I think we can subclass this PMC for specific OSes, and
> specific FileSystems if needed.
Is your implementation going to cope with one OS having several different
types of file systems mounted, that might have different specific behaviours?
I know that HFS+, ufs and ext3 all have various forms of flags/extended
attributes, and in turn I'd assume that a FileSystem PMC would have some
way of accessing them. So I'd assume that parrot has to cope gracefully with
this, and allow full access, although maybe not as far as automatic
detection.
Nicholas Clark
Alberto Simões
Nicholas Clark wrote:
> Is your implementation going to cope with one OS having several different
> types of file systems mounted, that might have different specific behaviours?
>
> I know that HFS+, ufs and ext3 all have various forms of flags/extended
> attributes, and in turn I'd assume that a FileSystem PMC would have some
> way of accessing them. So I'd assume that parrot has to cope gracefully with
> this, and allow full access, although maybe not as far as automatic
> detection.
That is a problem I've thought about, but that I don't know how to
solve. In fact, I'm offering to implement most of this PMC file, but I
can't go for those details (at least now) as I miss the knowledge :)
cheers
Alberto
Chip Salzenberg
is either substantially wrong or just a convenience wrapper around what's
really going on:
On Wed, Jan 25, 2006 at 09:10:50PM +0000, Alberto Simões wrote:
> $P0 = new .Path("/foo/bar")
[...]
> $P0.is_dir()
> $P0.is_file()
It is necessary that Parrot's filesystem interface make user-visible the
_event_ of measuring the attributes of a path _or_ an already open
filesystem object (e.g. calling stat() or fstat()). It must also represent
the bundle of measurements returned as some kind of PMC. (handwave handwave)
Perl 5 does this (fairly crudely) by returning a list of values from stat()
or lstat() which you can examine at leisure, and by special-casing the "_"
filehandle to mean "results of last stat".
The above-quoted example is only plausible if it's shorthand for, e.g.:
$P1 = $P0.stat # or lstat
$P1.is_dir()
$P1.is_file()
--
Chip Salzenberg <ch...@pobox.com>
Alberto Simões
> _event_ of measuring the attributes of a path _or_ an already open
> filesystem object (e.g. calling stat() or fstat()). It must also represent
> the bundle of measurements returned as some kind of PMC. (handwave handwave)
I agree with that.
> Perl 5 does this (fairly crudely) by returning a list of values from stat()
> or lstat() which you can examine at leisure, and by special-casing the "_"
> filehandle to mean "results of last stat".
We have stat() and lstat() working as well as perl 5 stat and lstat.
> The above-quoted example is only plausible if it's shorthand for, e.g.:
>
> $P1 = $P0.stat # or lstat
> $P1.is_dir()
> $P1.is_file()
>
Looking to this code, $P0.stat should return a Stat PMC object, so we
can call is_dir and is_file.
Other option is to specify that 'is_dir' and 'is_file' stat the file
everytime they are called.
For me, both options are reasonable. Chip's proposal have the advantage
of caching the info. Using is_dir and is_file to stat everytime, have
the advantage of not having a specific Stat PMC object.
Other option, is having one is_dir() and one cached_is_dir().
Chip Salzenberg
> Chip:
> >The above-quoted example is only plausible if it's shorthand for, e.g.:
> >
> > $P1 = $P0.stat # or lstat
> > $P1.is_dir()
> > $P1.is_file()
> >
>
> Looking to this code, $P0.stat should return a Stat PMC object, so we
> can call is_dir and is_file.
> Other option is to specify that 'is_dir' and 'is_file' stat the file
> everytime they are called.
(Call this paragraph "A")
I wouldn't call this 'another option'. Your two proposals in paragraph "A"
are compatible with each other.
> For me, both options are reasonable. Chip's proposal have the advantage
> of caching the info.
Oh dear, I goofed in my example. What I meant is actually compatible with
what you write in paragraph "A" above, namely, that:
$P0.stat
works, and
$P0.is_dir
$P0.is_file
is shorthand for
$P1 = $P0.stat
$P1.is_dir()
$P1 = $P0.stat # NOTE IMPORTANT SECOND CALL THAT I FORGOT LAST TIME, GRRR
Joshua Hoblitt
> For me, both options are reasonable. Chip's proposal have the advantage
> of caching the info. Using is_dir and is_file to stat everytime, have
> the advantage of not having a specific Stat PMC object.
> Other option, is having one is_dir() and one cached_is_dir().
Regardless of what Chip intended to say, please don't go caching the
state of a filesystem...
-J
--