Re: DogCows or Polymorphism in the Hurd

[Tom Bachmann]

Jonathan S. Shapiro wrote:
> The problem cases are:
>
>         grep something-that-is-DogCow
>
> or
>
>         grep -R anything

Right, I forgot the latter.

> > I guess you mean the logical hierarchy? So that what e.g. ls shows us? 
> > Because this poly-type object is still one file, and we do not even have 
> > a reliable way to insert the new logical files into the hierarchy.
>
>
> If we cannot insert files, then the translator either needs to make the
> directory appear to be read only or this bug needs to be fixed.

This cannot was more intended to be a "should not". It is still _one_ 
file and I think making one file appear as multiple ones will cause more 
troubles than it removes.

Maybye we're speaking cross purposes and I just don't understand the 
thing. Assume I move a .tar.bz2 file from some where into an empty 
directory. Then I use my "completely-polytype-unawayre-ls", what will I 
see? And will I see something different when using the hurdish ls. If 
so, what and why?

> > > Using the poly-type approach would remove all ambiguities: Applications
> > > would either see a file or a directory, but not both.  Applications who
> > > _know_ about hybrid types can use the new functions to switch facets
> > > explicitely.  If a user wants to use an application with a hybrid type,
> > > he will have to make his intent explicit by providing the node with the
> > > right facet type to the application.
> >
> > What I do not understand is what applications without knowledge of this 
> > approach. They would see objects that neither provide directory nor file 
> > semantics.
>
>
> This is not correct. Have a look at my ascii art (assuming it survived;
> use a monospace font). In effect, you have a "file" object that has two
> new methods:

So you, in fact, want to set a default facet (file)?
At lest that's how i interpret your statement + this graph:

    FsObject
     /   \
    File Dir
     \   /
    FileDir
--
-ness-