Tim Rowledge <tim at sumeru.stanford.edu> wrote:
	I really think that comma is a good selector to use, since we
	really are concatenating elements on to a path.

	People really do need to understand that filenames are not
	strings and you can't properly build them by simply sticking
	strings together with slashes in there somehow.  There's a bunch
	of truly awful code lying around the image that makes that
	assumption and it needs to be excised, root and branch.

Suppose we think of a "file name" (more generally, a URI) as
a "base" and a "path".  (A "base" might be a drive letter in DOS/Windows
or a disc name in MacOS.)  Suppose we agree that a "path" is a sequence
of names.  (Not always true.  In PR1MOS, a path was a sequence of
name optional-password _pairs_.)

So "A:\B" extend-with "C" is "A:\B\C"

This is NOT the same as concatenating two sequences.
It is ADDING ONE ELEMENT to a sequence.
(More precisely, given (base,path) and name we are returning a new
(base,path++[name]) object.)

Consider
    'ab' , $c

This is not at all allowed in Squeak.
You get 'Error: Characters are not indexable' if you try it.

So the analogy just plain does not hold.

If we were talking about writing
    FileDirectory default , #(foo bar ugh)
then yes, the concatenation analogy would hold.  But for
    FileDirectory default , #foo , #bar , #ugh
it does not hold.

<CSOTD>
"In class SequenceableCollection category copying, add"
append: anItem
    ^self , (Array with: anItem)
</CSOTD>

_This_ is the operation that adding a name to a path most resembles.
I agree that

    ((FileDirectory default append: #foo) append: #bar) append: #ugh

is not as concise as using commas, but it is a lot less confusing.

What I don't understand is why FileDirectory hasn't had operations
    fd parent		(equivalent of ..)
    fd child: #name	(the operation whose name we're arguing about)
since day 1.