Disambiguating identifiers that pertain to files, folders, and various parts of their paths is a task that comes up repeatedly in my work. For one reason or another, these often tend to be of wide scope, often Readonly. For instance, I may have some blivet for which I have both files and folders at several levels of the filesystem tree. Different operations may require just the name itself, the absolute path, or some relative path. One would like to be able to tell at a glance which of these some $blivet may be.

Ideally, bumps would not be required but alas, it's better to append bumps to identifiers than to have them collide. So, I'm going to propose a bump convention for these critters. To all those who object to bumps on principle and will go to any lengths to avoid them, my apologies.

My perspective is:

In no way do I discuss here ways of getting or relating these things; only the strings used to identify them. So, I offer a simple table of barewords: 

----------------------------------------------------
                                            Table 01
----------------------------------------------------
id                  object
----------------------------------------------------
blivet              data; not a path part at all

blivet_file_name    'blivet.jpg'
blivet_file_rel     'foo/bar/blivet.jpg'
blivet_file_abs     '/home/me/foo/bar/blivet.jpg

blivet_dir_name     'bar'
blivet_dir_rel      'foo/bar'
blivet_dir_abs      '/home/me/foo/bar'

blivet_path         all *path* bumps forbidden
----------------------------------------------------

[download]

My interpretation of wfsp's conventions: 

----------------------------------------------------
                                            Table 02
----------------------------------------------------
id                  object
----------------------------------------------------
blivet_file_name    'blivet.jpg'
blivet_file         '/home/me/foo/bar/blivet.jpg

blivet_dir_name     'bar'
                 or 'foo/bar'
blivet_dir          '/home/me/foo/bar'

blivet_path         all *path* bumps forbidden

blivet_root         'home/me'
----------------------------------------------------

[download]

My interpretation of ikegami's conventions: 

----------------------------------------------------
                                            Table 03
----------------------------------------------------
id                  object
----------------------------------------------------
blivet_fn           'blivet.jpg'
blivet_qn           'foo/bar/blivet.jpg'
blivet_fqn          '/home/me/foo/bar/blivet.jpg
blivet_fh           FileHandle->new("$blivet_qn")

blivet_dir_fn       'bar'
blivet_dir_qn       'foo/bar'
blivet_dir_fqn      '/home/me/foo/bar'
blivet_dh           DirHandle->new("$blivet_dir_qn")
----------------------------------------------------

[download]

Fellow Monks who have better ideas are encouraged to state them; I will collect any coherent alternatives into this node.

Updates:

2010-03-30: Add Tables 02, 03.

2010-04-01: I may need to stress that at this level of abstraction, I consider all the following equivalent: 

blivet_path
$blivet_path
-blivet_path
blivetpath
blivet{path}
(blivet, path)
blivet.path
blivet->path

[download]

Replies are listed 'Best First'.
Re: Path Part Identifiers
by shmem (Chancellor) on Mar 30, 2010 at 07:11 UTC

    Whatever convention you use: use it, as long as it is good for you. It is good for anybody else too, if it's documented. But be consistent.

    That said, I have the same uneasieness with splitting up $blivet into variables with a pre- or postfix as I have when I see $var_1, $var_2, $var_3 instead of @var.

    If you have a thingy which is this or that depending on context and/or has some attributes associated, use a suitable container for them. This can be a hash or an object.

    So, I'd rather say:

    $blivet->file_name;
$blivet->file_rel;
$blivet->file_abs;
# and so on

    [download]

    Concatenating a identifier with a functional part - i.e. some kind of index - into a new identifier just looks wrong to me.

[reply]
[d/l]
[select]

Back to Meditations