[PD] pdmtl abstractions questions and comments

[Frank Barknecht]

Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

> >this follows the http://puredata.info/docs/developer/CodeGuidelines
> 
> Ok, I don't particularly remember reading them back when they were posted. 
> Now that I read them I'd like to say that the part about namespaces is 
> quite bad: if I make a more descriptive name for a class that is really a 
> lot like [poil], it would be something that ends in "_poil". However this 
> means that a prefix is added to the name. The same section says that 
> prefixes are to be turned into geiger namespaces, that is, folders. Let's 
> say that the folder is named "patate". But then I cannot use the original 
> [poil] anymore in that folder because pd picks up the locally defined 
> [patate/poil] as being poil itself, hiding the prefixless [poil] that I 
> need. Therefore a prefix is required. Then I might call it 
> patate/patate_poil.pd, but that's redundant, so I remove the folder so 
> that it's just called [patate_poil], and then we're back to prefixes. 
> However if pd wasn't doing that and if there wasn't [import] then the 
> slash wouldn't be anything more than a tilted underscore. So what are 
> those guidelines good for?

Actually that is why I didn't yet use directory prefixes for my
abstraction libraries, especially the [list]-abs.  Without their
prefix -- [list]-abs is using a dash instead of an underscore or a
slash, because underscores are harder to type on german keyboards and
because not following guidelines leads to more fun in life --, objects
like [list-abs] or [list-moses] are impossible to use in Pd anyways,
as [abs] and [moses] are builtins. 

So a prefix directly in the object name is necessary. "list-" to me
looked like the most natural choice - and it doesn't need "Shift" on
german keyboards to type, so I was set.  

The choice of pdmtl was "list/". Another good and obvious choice, but
to me it doesn't really have any advantages over "-" (and needs
"Shift" on german keyboards...) Unless you stick to unused names only,
you always need to keep the prefix in the object name. 

If someone else does an abstraction collection for lists, I'd say,
"list_" or "list." are two other good choices.

Where directory prefixes shine however is for making packages of
externals and abstractions. Pd-extended is the prime example: It can
ship all five [counter] objects, which would be impossible without
subdirectories for each collection. Whether shipping five counters is
desirable is debatable, but at least people have a choice. 

However shipping objects (or classes, as you suggest to call them) in
subdirectories creates a possibly uncomfortable side effect: It
introduces an additional, possible prefix: the directory name. So
people start to use objects called [list-abs/list-abs] just because
for packaging reasons, list-abs.pd in pd-extended lives in a directory
called "list-abs". Now that's what I call redundancy: Instead of one,
we get two prefixes. At least my help-files still work.

pdmtl may face a similar or worse problem when people start using
objects with names like [pdmtl/list/op]. Here not only help-files will be
broken, as the help file "list/op-help.pd" uses an object called
[list/op] which is unavailable unless "pdmtl" is in the path.
Actually all objects using [list/x]-objects are broken then! 

To somehow be prepared for that pdmtl would need to use [import] or
[declare -path ..] in every abstraction, and take note, that [declare
-path ..] will also activate all other subdirectories of ptmtl for
that patch - mostly this won't be a problem. 

All this to me seems to kind of pervert what Guenther Geiger actually
intended when suggesting directory prefixes and initiating the
CVS-repository. Instead of shipping five [counter]s, one [counter]
would be shipped as the default [counter] directly in extra, other
counters would be hidden in subdirectories for special use, but be
deprecated. The reality now is, that [flatspace] announces that it is
deprecated, and the "Path" window is filled with more entries than it can
handle.

> I think that category names have to be figured out pretty quick if people 
> are expected to start using the names in backwards-compatible ways. Else 
> you get into what is called "bit rot" - a program is not just the contents 
> of source files, it's also a set of relationships with its environment, 
> and especially, its direct dependencies.

[list-abs/list-abs] is bit-rot.

> >Tags instead of categories would be much better.
> 
> If you mean that there wouldn't be namespaces and instead there would be a 
> non-arborescent taxonomy whose purpose would still be to organise similar 
> objects together documentation-wise, then I would say that I agree.

I had to look up arborescent, after that I agreed, too.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__