Hans Reiser wrote:
Peter Foldiak wrote:
On Fri, 2004-09-10 at 06:22, Hans Reiser wrote:exactly.
He asked me, why not just access a filename's size as filename/size?
I now understand that you need a way to distinguish between something
like
shoe/size
and
shoe/.../size (or shoe/..size)
The first one is the size of the shoe, the second is the automatically
generated size of the file (object). You would get into trouble if you
would not allow the user to use shoe/size for shoe size. Peter
Of course, problem/shoe/size could refer to shoe size in centimeters of a problem shoe or the size of the problem relating to a shoe in units of reporters providing press coverage of it or....
So there are lots of opportunities for ambiguity in semantics....
Still, widely used builtins seem like they should be moderately evasive of commonly used names.
You know, if tools all need to be rewritten anyway to deal with the file metadata "directory", then why not change the symbol that delimits the metadata key?
Everyone likes ':', so we'd have "problem/shoe:size". (Don't bother to complain about files which have : in them, because I already know it sucks, but it's an example.)
See, unless you can come up with a way to seamlessly make old tools work with the new semantics, then there's no reason not to make more than one change to tools at at the same time.
Also, if you take the ':' example literally, then the file system would need to be able to figure out that a file whose literal name is "C:\MYPR0NDIR\BODY_PARTS.JPG" isn't referring to metadata for a file named "C". :)