pathnames

[Chris Bitmead uid(x22068)]

>Chris Bitmead uid writes:
> > Take the example of a document with several chapters. You've probably
> > got in mind some Lisp function which changes a "Chapter" object and
> > saves it to the disk. Something clever in the background makes sure
> > the old version is saved somehow.
> > 
> > I've got in mind a function (chapter-edit) which takes a "Chapter" as
> > argument and returns a new Chapter object as a result. The old version
> > is not changed in true functional style. Another function (book-edit)
> > takes a "Book" object as argument, and then calls (chapter-edit) to
> > modify chapters. Instead of modifying the book object, (book-edit)
> > makes a new book with the all the latest versions of the chapters and
> > returns the new book object. The old version of the book object is
> > left as-is. (In functional style)
>
>Doing something like this would seem to me to be quite difficult,
>bug-prone, and communication intensive.  Suppose I then have a
>publications object which is a collection of book objects and article
>objects, and the book objects are collections of chapters.  Now I call
>(chapter-edit ch7), where ch7 happens to be from book3.  If
>chapter-edit returns a new chapter object, then book3 is out of date,
>and my publications object no longer contains all the latest
>revisions.  Either I'd have to explicitly create a new book3
>containing ch7, and explicitly create a new publications object
>containing book3, or I'd have to implement all sorts of change
>notification methods to trigger the apropriate actions in all the
>container classes.

Well you wouldn't be calling (chapter-edit ch7) in isolation generally
speaking. (chapter-edit) returns a chapter. It's up to you as the
programmer to do something sensible with it. For example...

(let* ((book (get-book publications "Treasure Island"))
       (chapter (get-chapter book "ch7")))
      (set! publications
         (pub-replace-book publications 
            (book-replace-chapter book 
                (chapter-edit chapter)))))


>Unless one restricts completely to an object oriented subset of Common
>Lisp, I'd believe that anything along the above lines would be
>unworkable.  Either the user, the programmer or the system would have
>to track down all references to the old ch7 and either leave them or
>rewrite them to point to the new ch7.  This would include all lists of
>book and or publications and or chapters that I happen to have kept
>around anywhere at all.

It is a general problem with versions, as to what to do when you have
a new version. Should pointers continue to point to the old, or should
they point to the newest, or should they point to the newest "stable"
version where someone defines a stable attribute.

That's why versioning is very application specific. It would be wrong
to assume that all references should always point to the latest.

If you want a mechanism to always refer to the latest, then a lisp
reference is the wrong abstraction for doing that.