Re: silent semantic changes with reiser4

Hans Reiser
2004-09-10T17:51:43Z

Timothy Miller wrote:

>
>
> Hans Reiser wrote:
>
>> Peter Foldiak wrote:
>>
>>> On Fri, 2004-09-10 at 06:22, Hans Reiser wrote:
>>>
>>>
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>> exactly.
>>
>> 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?

because it is useful that it is only a style convention. Changing the
symbol makes it mandatory to distinguish metafiles from files.

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