pathnames

[BRIAN SPILSBURY]

CB> "X" is an abstract attribute that you have assigned to an
CB> object. Chapter "X" version 1 is not Chapter "X" version 2. They are
CB> different things. The extent that they are in some way equivilent is a
CB> notion that you should impose through your data structures, not
CB> something that the underlying language or file system should have any
CB> care about.

It depends on how the identity for that construct is defined. If the
object is 'Chapter X' of 'Book Y', then it transcends the versioning.

If I want 'Chapter X Version 1' to define the identity, then
you are indeed correct. I was assuming the previous as the more
natural, and the more useful.

I would personally have both, use destructive modification on the
'Chapter X' identity, and leave the 'Chapter X Version 1' object immutable.
All this requires is for the chapter X construct to support the 
interface of the 'Chapter X version 1' construct.

CB> >Think about objects, they're places where destructive modification
CB> >is what makes them make sense, as contained dumping grounds for
CB> >side-effects.
CB> 
CB> No, modification is not "what makes objects make sense". Object
CB> orientation and destructive side effects are orthogal issues. Object
CB> orientation is equally as useful even in the absence of destructive
CB> side effects.

It is if you're talking about objects as containers, as opposed to
OOP. Sure you an have your containers immutable, but then you lose
a lot and require enormous communication and paperwork systems in
order to propagate changes if other objects are expected to get hold
of the new object without explicitely re-requesting it, which is
the situation here.

CB> I can't see how a transparent wrapper object which bounces requests is
CB> any less open to race conditions.

Well, its not hugely less open, but it does mean that I can't cache the
latest version reliably. Having the two form of identity as above
solves this nicely. If you want Ver 12, you get Ver 12, if you want Chap 3
of the book as is, then that's what you're dealing with, but it will
always bee the latest ver, quite possibly at the least convenient times,
so you wouldn't use that for editing, but you might well use that for
a browser/searcher.

CB> If I have a reference to Chapter "X" version 3.2, I expect that to
CB> remain a reference to V3.2. I don't expect some magic to transform it
CB> into something else.
CB> 
CB> If you *do* want some form of magic then you should explicitly invoke
CB> the right incantation. (Abracadabra-give-me-the-latest) or
CB> (Abracadabra-give-me-the-biggest) or (Abracadabra-give-me-the-latest-
CB> that-has-been-published-by-my-printer)

I agree entirely, although I'd leave out the abracadabra :) We might
get fnords popping up here and there after a while.

CB> Basicly you are putting forward all the arguments for a non-functional
CB> approach to programming, and I am advocating a functional approach to
CB> solving problems.
CB> 
CB> I happen to think functional is better, but I would certainly hope
CB> that LispOS would not make non-functional the defacto standard because
CB> of some design decision.

No one paradigm reigns suprime, which is why lisp is a bastard language, why
C is a bastard language, and um, well, C++ doesn't even need a reason.

I prefer a balance where possible, between extremes.

Brian