🚀 go-pugleaf

Hans Galema wrote:

> That is just a choice I suppose.
> You could as well have decided always without. Or is there more 
> behind it ?

It's part of our coding standards. Shortage of resources (ie;two
people) and size of code base (~20MB) plus the nature of our work
environment (task driven and frequently interrupted) mean that coding
and data standards are important. If a bug stops an engineer getting
their work done we have to be able to switch track and fix it as
quickly as possible. We don't have the time to relearn minutae of
source code nor to document every last detail.

Another reason is that we have had to implement path parsing functions
and by coming up with a definitive set of rules it's easier. We tend to
favour pedantic algorithms in our code. That way (in theory) the state
of an executing process is more easily predicted.

FWIW:

4.2.1. Definition:Object name
A sequence of any characters except �\� and �:�.

4.2.2. Definition:Volume ID
An object name and trailing ':'.

4.2.3. Definition:Directory path
A series of object names all of them having a trailing '\'.

4.2.4. Definition:File name
An object name appearing at the end of a directory path.

4.2.5. Definition:File name extension (informational only)
An object name that follows the rightmost �.� in a file name. 

4.2.6. Definition:Stream name
An object name following a file name and separated by ':'.

A fully qualified file path is therefore:

[<Volume ID>]\<directory path><filename>[:<stream name>]

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html