[PD] pdmtl abstractions questions and comments

[Mathieu Bouchard]

Frank a écrit:
> Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
>> [...]
>> 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

Actually see my mail to Patrice Colet (patco) about the mistake in what I 
wrote. But you seem to have figured out the mistake and figure out what I 
meant instead:

> objects like [list-abs] or [list-moses] are impossible to use in Pd 
> {without the prefix} anyways, as [abs] and [moses] are builtins.

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

So far, Max seems to be using ".", for example "jit."; because of this, 
I've used the "." prefix but for "lti." classes; actually I also used it 
for some PureUnity classes, initially like "f." "~." "#." to mean float's, 
signal's, grid's, in a way that is meant to be used as [$1.hello]. I have 
changed this to around to [hello.$1] because of pd 0.40 and of personal 
preference.

> 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.

Edit the five source files, changing the name in it for something else. Is 
that so impossible? It might not be pretty, but I wouldn't call it 
"impossible".

> 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.

I'd call this three prefixes: "list" occurs twice, then "abs" occurs 
twice, one of which is a prefix for the other one. I usually call this the 
"Java disease", but I wouldn't want people to think that this is specific 
to Java or that I call it that way just because of my general dislike of 
Java.

> 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!

Therefore, whether a folder is intended to be a package (prefix) or a 
plain folder (that'd go in -path), is something that has to be decided in 
advance for every folder and has to be stated in some way. I mean, one can 
get around it, but it causes trouble eventually, because of unability to 
figure out whether the "real name" of an abstraction is [list/op] or 
[pdmtl/list/op].

> All this to me seems to kind of pervert what Guenther Geiger actually 
> intended when suggesting directory prefixes and initiating the 
> CVS-repository.

Actually, it never occurred to me that those two things were related. I 
think that I joined pd-list shortly after the CVS created, but I don't 
recall that anyone said (in the last five years of pd-list) that the whole 
externals/ thingie had to do with Geiger namespaces. So, if anything got 
perverted, it's quite natural, because the original goals have not been 
re-stated often enough.

> The reality now is, that [flatspace] announces that it is deprecated,

I admit that I don't really remember what [flatspace] is, if I ever knew. 
I think that I largely skipped over it.

> and the "Path" window is filled with more entries than it can handle.

Apart from what the intention might have been about paths or libs 
(libdirs), this is not a problem with Hans's work per se, it's a problem 
in u_main.tk, and it's very possible to fix it: e.g. 
http://artengine.ca/desiredata/gallery/pdrc_5b.gif and the same user 
interface also exists for -path and -helppath separately.

>> 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.

Well, i've only seen the word "bit-rot" to mean things that result from 
not updating software to changing interfaces (I'm not counting the meaning 
of it that has to do with physical media). Thus I don't really know what 
you mean by [list-abs/list-abs] is bit-rot: it's not like your [list-abs] 
has gone unmaintained for years such that the definition of pd (or what pd 
is in practice) has changed such that is has become contextually broken or 
outdated or irrelevant...

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada