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