[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DogCows or Polymorphism in the Hurd
From: |
Marcus Brinkmann |
Subject: |
Re: DogCows or Polymorphism in the Hurd |
Date: |
Thu, 09 Feb 2006 03:54:50 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Wed, 8 Feb 2006 23:25:39 +0100,
Filip Brcic <address@hidden> wrote:
> In recent versions of less on Linux (I have Gentoo Linux, I don't know if
> this
> is less's feature, or Gentoo patch), when I say less foo.tar.bz2, I'll see
> the contents of the foo.tar.bz2 as a directory. On Linux it is made as a
> feature embedded in the less program. If I click on the foo.tar.bz2 in KDE, I
> will enter that file as a directory. On KDE that feature is implemented very
> much like gnu/hurd translator. Kio-slaves effectively translate from
> something (smb, targz, ftp, ...) to files+directories structure. The Gnome
> has vfs which should look similar to kde's ioslaves (I don't use Gnome, so I
> am not sure how it is implemented). Those are the features I would like to
> see in the system. If I enter the command cd foo.tar.gz, I would like to
> enter that archive. I don't want to think about foo.tar.gz:asDirectory and
> other variants. In OOP language, I would like to see an implicit cast of the
> FileDir object into the file and into the dir where applicable.
As you said yourself, less and KDE/Gnome applications are aware of the
hybrid types, so they know how to handle them.
The cd command can not operate on files, so it treats its argument as
a directory no matter what.
In both cases, no ambiguities arise. The problematic case is legacy
applications that can work on Files _and_ can work on Directories, and
get confused if something is a FileDirectory (DogCow). This is the
fundamental problem you have to solve if you want to combine both
interfaces into one.
In OOP languages, you have to tell me a simple, implementable rule
that tells me when a legacy application should see a cast into file
and into dir if the application does _not_ specify the desired type
explicitely.
To make this more explicit: Directory has its own io_read. So has the
File interface. It seems straightforward to always use File::io_read
for io_read, because the Dir::io_read function is so darn useless. On
the other hand, io_stat is more interesting: Here we create a mixture
of the Dir::io_stat (ST_IFDIR) and the File::io_stat (size), for example.
How can this ever make sense to legacy applications?
I understand your desire to make this work, but if you really want
this you have to help is in understanding how it could made work in
the problematic cases. :)
Thanks,
Marcus
- Re: DogCows or Polymorphism in the Hurd, (continued)
- Re: DogCows or Polymorphism in the Hurd, Marcus Brinkmann, 2006/02/07
- Re: DogCows or Polymorphism in the Hurd, Patrick Negre, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Tom Bachmann, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Filip Brcic, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Tom Bachmann, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Filip Brcic, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd,
Marcus Brinkmann <=
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/09
- Re: DogCows or Polymorphism in the Hurd, Patrick Negre, 2006/02/08
- Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/08
Re: DogCows or Polymorphism in the Hurd, Bas Wijnen, 2006/02/03
Re: DogCows or Polymorphism in the Hurd, Jonathan S. Shapiro, 2006/02/07
Re: DogCows or Polymorphism in the Hurd, Bas Wijnen, 2006/02/08