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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
