[Zope3-dev] Notations for paths

[Florent Guillaume]

On Thu, 2002-12-19 at 19:01, Phillip J. Eby wrote:
> >Why go to those lengths when we can have a perfectly effective location
> >as a tuple of names in trivial bijection with a string?
> 
> What lengths?  Having a class?  Calling it?  Seems to me like very little 
> work to ensure correct behavior.  Heck, I'll write the class myself, if you 
> want.  :)
> 
> The point is that it's bad design to:
> 
> 1) shuffle around tuples for something that *isn't* a tuple

But it is! It's a sequence of steps for traversal.

> 2) Create functions for manipulating tuples that people are supposed to use 
> (but won't, because it'll seem too simple to just "do it themselves" and 
> manipulate the tuple directly)
> 
> Now that it has become clear that it doesn't work, the simple and obvious 
> solution is to subclass tuple, i.e.:
> 
> 
> from types import StringTypes
> 
> class ZopeLocation(tuple):
> 
>      def __new__(klass, stringOrLocation):
> 
>          if isinstance(stringOrLocation,klass):
>              return stringOrLocation
> 
>          if isinstance(stringOrLocation,StringTypes):
> 
>                 path = stringOrLocation.split('/')
> 
>                 if not filter(None,path):
>                     # string was all '/'...  remove one empty element
>                     path.pop()
> 
>                 return super(ZopeLocation,klass).__new__(klass,path)
> 
>          raise TypeError("Not a string or location", stringOrLocation)
> 
>      def __str__(self):
>          path = list(self):
>          if not filter(None,path):
>              # all empty parts, add one extra
>              path.append('')
>          return '/'.join(path)
> 
>      def traverse(self, start):
>          # XXX do something useful...
> 
>      def commonPrefix(self,other):
>          # XXX do something useful...
> 
>      # etc...

*That's* what I call "going to those lengths". A full blown class when 
a tuple fits the bill.

> Now any other functionality associated with locations can be added to the 
> class.

What's wrong with convenience functions? Why does everything need to be
a class? I'm all for encapsulation when it brings you something, but
here I really don't see that it's needed. And the functionnality you're
proposing to add is standard sequence manipulation. Why rename them and
put them in a new class?

> And, if it's decided the string format or the internal 
> representation needs to be different for some reason, why then it can be 
> changed in one place.  And, because nobody knows it's a tuple unless they 
> read the code, they won't go messing with it and spreading bugs all over 
> the place.
>
> If y'all think path manipulation problems are widespread *now*, just wait 
> till non-core Zope developers get a hold of it.

If the proposal to regularize the tuple format that Steve proposed and
that I'm championning is used, there won't be that sort of bug anymore.
You'll use split and join and that's it.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com