Re: [e-lang] File API taming

On Sun, March 22, 2009 02:27, Kevin Reid wrote:
> On Mar 19, 2009, at 21:35, Marc Stiegler wrote:
>
>> Dean Tribble and I have a long-running low-key but adamant
>> disagreement about making the file objects have opaque paths, versus
>> supporting a method like file.getPath(). I use getPath() in E so
>> frequently, I cannot even characterize the circumstances under which I
>> do it. Well, I can characterize one circumstance pretty well.
>> I write lots of user interface code, and the path/name is the
>> identifier used to communicate with the human being. So for example,
>> the CapEdit app on CapDesk wants to know the name of the file so it
>> can display that name in the title bar.
>
> [copying-and-redirecting-to cap-talk because this message has become
> general capabilities/UI stuff, not taming design]
>
> Here is a glib answer, and a ramble, for further argument:
>
> The application should not need to know the name of the file.

====

> So how do you name a nameless file? Assigning serial numbered petnames
> like "untitled-359" would be bad.

Seems to me like the first assertion would be wrong. There seems to be
something lost by the application not being allowed to know the name,
while there is nothing gained, at least from a least authority perspective
by disalowing it.

If you view the name of the file only as a petname within the namespace
defined for the containing directory, sharing the value of this petname
without sharing a capability to the containing directory would not
transfer any authority, especialy if authority to the file itself is
shared already.

Viewing names like this however does not make the name a property of the
file object, but a property of the relation. You may use this concept to
create some sort of 'relation' proxy object that transparently proxies the
file object and extends the interface with a getName() method.

Extending this concept to a getPath() implementation however seems to give
rise to possible confusions. People are used to using absolute paths for
designation, thus providing a full path with an artificial getPath()
implementation may lead people to mistakingly look for ways to use these
paths as designations.

Rob