Hans-Christoph Steiner wrote:
Part of putting all of the code into a central repository
....like herding the sweetest, but most unwilling cats: not all developers will plant their code in the CVS.
and also compiling all of the contributed objects as individual files
Unless I misunderstand you, this requires breaking up existing libs into separate objects. Lots of work, and the original developers won't want to do it, and won't want to touch it after someone's dismantled it.
allows us to eliminate such conflicts.
No, that means you'll still have two different, say, "counter" single-entity libs and hence [counter], and users will still never be able to reach both of them.
Do you mean allowing the user to rename the lib? Doesn't that break load-time linking? And then break the patch on everyone else's machine?
Load-time namespace management will allow ALL objects to be reachable, even into the infinite future, whether or not they are in simple (1 entity) or aggregate libraries, no matter if a developer names ALL his objects the same [thing], as long as the library names are different.
So if you use the packages (Debian, Windows, MacOS X), then there won't be conflicts if you don't use any libs.
Who will make the choice of which objects 'live' without renaming, and who 'dies' (gets renamed)? Even dictionaries allow different definitions of words, and multiple entries, and they're all accessible to those who wish to access them.
To expand on my core arguments: 0. Not all users are C developers, nor do they wish to be..
- Not all developers will plant their code in the CVS.
I imagine the most important one never will do so.
- All users want arbitrary access to all objects, with
a) no unresolvable conflicts, and b) an easy workaround for any conflicts, and c) easy to find, install, and successfully reference objects.
Example, unresolvable as of July 18, 2004: lib1 contains [counter](2 inlets) and [slope](2 inlets) lib2 contains [counter](4 inlets) and [slope](4 inlets) All four objects are useful and interesting, and do what they say in different ways. All should be reachable, without forcing literal renaming, or forcing tortuous workarounds.
Note: lib_obj naming is not 'renaming', but 'name extension'
- Not all developers will choose to check the name of their new objects
against the
WWW to guarantee uniqueness, because that would force them to choose YAASIN
(Yet Another Arbitrary Silly Irrelevant Name) for their objects.
Perhaps better to force
them to use a thesaurus (see attached pic, courtesy Visual Thesaurus).
- Objects evolve. There are early versions of objects which are fast
but featureless. Later versions (same name) have great features, but are slow. The user should be able to choose.
Conclusion: some sort of easy user-end name choices are needed.
I personally like pseudo-heirarchical built-in name mangling as expressed in maxlib, followed by path-heirarchical with a lib-name 'namespace' separation, or (perhaps) a true namespace implementation.
If the argument is that it's a lot of work for a few conflicts, please note that there are nearly a hundred actual conflicts in the Pd universe of objects right now. This is because every weirdly synonymical-yet-irrelevantly-named object represents a conflict resolved by the developer at coding time. That resolution was achieved in an extraordinary, non-mnemonic and ultimately user-alienating way. Each of those conflicts continually re-affects every user to tries to use Pd.
I disliked irrelevantly-named objects in Max, and I dislike them even more in Pd, because in this new, developing language, they're unnecessary. We'll never know what those irrelevantly-named objects (INOs) would have been named if there had been another way.
Historical interpretive note:
In Max and Pd and others, names are short ONLY to take up minimal space
on the screen, because
they are perforce textual languages, and texts, not diagrams. There is
no functional meaning assigned
to the square boxes without the name present. These are English-centric
and are likely to remain so,
even though this does not serve users(too-short names), or international
users(must know English), all
that well.
Why make this point?
In some other gui-based languages, such as eyesweb, object names are
long, and are descriptive,
but objects in patches are represented primarily as icons, perhaps
accented and differentiated from its
functional family members with an additional symbol or letter. These
are inherently more
internationalizable. There is a certain greater compactness and visual
understandability which _can_
be achieved graphically, although eyesweb does not achieve this.
Worse, the ease of mutating an object
is missing in eyesweb - an object cannot be changed "on the fly", but
must be newly created, and the old
one deleted, along with all its prior connections, which must then be
rebuilt.
"Freedom of choice, it's what you've got. Freedom from choice, it's what you want." --- Devo
L
.hc
On Jul 18, 2004, at 4:56 PM, Lex Ein wrote:
Problem: Unique objects exist in more than one library with the same name, but different function, with no ombudsman or czar to arbitrate who gets the name. This forces library loading order to be an issue: IEM's gate vs cyclone's gate.
So I offer two thoughts: (if this has been discussed before, I couldn't find it.) 1. If, at load time, external objects maintained their library name persistently, then objects could be absolutely selected from a particular library at creation time in the patch. This would eliminate the effect of library loading order and increase reliability. So instead of [prob 2 4 5] someone publishing a patch could specify [mJlib/prob 2 4 5] to guarantee correct operation, and alert the user immediately to the required library, with no further documentation needed..
- If Pd had a option to enable/disable "object path display" in the
GUI, ALL object names could be displayed with their library path or not, in edit mode.
Advantages: 1. No need to make up ridiculous non-mnemonic names for objects which have nothing to do with their function, simply to avoid a dreaded name collision. 2. No more torture for users trying to figure out why patches don't work, especially for objects without documentation which shall remain unnamed here.
Disadvantage(s): Not backwards compatible. However, the patch or abstraction can be easily edited as text to remove the offending path, and it STILL alerts the user to the need for the correct library..
It's just a thought.
L
