[PD] external loading suggestion

[Lex Ein]

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

1. Not all developers will plant their code in the CVS.
I imagine the most important one never will do so.

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

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: count.gif
Type: image/gif
Size: 3767 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20040718/c1fabcfa/attachment.gif>