[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

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. :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]