[Zope3-dev] Notations for paths

Phillip J. Eby pje@telecommunity.com
Thu, 19 Dec 2002 10:54:55 -0500


At 03:53 PM 12/19/02 +0100, Florent Guillaume wrote:
>Steve wrote:
> > Absolute paths and simple relative names (one step relative paths) are
> > used in Zope far more than relative paths. If we're always clear when
> > we're dealing with absolute paths, we don't need the '/' or ('',) at the
> > start, so we can use the simple expressions above.
> >
> > We could then say that relative paths must start with "./" or ('.',).
> >
> > Examples of relative paths:
> >
> >    ('.', 'foo', 'bar')
> >    './foo/bar'
>
>I actually quite like this, but it's a big departure from Zope 2 so
>maybe it would be difficult for developers.

Maybe I missed something, but why not just consider an empty string in the 
first element of the tuple to mean the path is absolute?  It works just 
fine in PEAK.

Actually, PEAK's ComponentName objects are parsed such that:

'foo/bar' means "acquire foo, then traverse to bar"

'/foo/bar' means "go to the root, then traverse to foo/bar"

'./foo/bar' means "start here and traverse to foo/bar",

and '..' in a path part is interpreted as going up a level.


But I doubt you want to support all of that in Zope.  You may, however, 
want to consider using a tuple subclass instead of a plain tuple, since the 
type can implement the conversion to and from strings, and it can have an 
__implements__, etc.  If its __new__ method is passed an object that 
already is a location, it can simply return it in place.  This makes it 
easy for routines which take a string or location object to simply call the 
location constructor on their input to ensure it's a valid location.

We *really* shouldn't have code making tuples and strings and all that 
other crud all over the place.  As the patterns of manipulation become 
clear (e.g. connect these two paths, find the common part, etc.), you can 
add methods to the location class to handle them.

Anyway, the point is that the representation of locations can and very much 
*should* be encapsulated.  Unencapsulated representations such as these 
were a major pain in Zope 2.