[PD-dev] A Solution: abstraction and external name collisions

[guenter geiger]

On Sat, 24 Apr 2004 zmoelnig at iem.at wrote:
> Zitiere "B. Bogart" <ben at ekran.org>:
>
> > Hey all,
> >
> >
> > Could this method be applied to externals as well?
> >
> > markex/counter or mex/counter
> > cxc/counter
> > cyclone/counter or cyc/counter
> >
> > Of course you break all the old patches if you have to use new names,
> > but it provides a facility where you use the object you want rather than
>
> this reminds me of my (long ago) proposal to use "." (a dot) as a separator
> between library name and external.

One of the arguments for using single externals has been that we can
structure them exactly in the way Ben suggested. More than that, you have
the C++ "using ..." clause for free by adding the path to one of the
external collections. Then you can use them without prefix.

Example:

We would have to structure the externals into subfolders of
extra ( e.g. .../extra/zexy/makesymbol.pd_xx). If you want to use them
directly, just add zexy/extra to your path, call it with makesymbol
otherwise load makesymbol with zexy/makesymbol.

For libraries, you can put them into a subfolder (extra/zexy/zexy.pd_xxx)
and make soft links from every object in the libray to it.
makesymbol.pd_xxx links to zexy.pd_xxx etc...

Not new, but a nice concept that doesn't need code changes. It has
been used by Miller with the lrshift~ external too, thats were I got
the idea from in the first place.

Guenter


> my implementation (which i posted to the list) was done in pd (and not in the
> libraries): upon loading the library name was automatically prefixed to the
> actual object-name, eg "Gem.scale".
>
> of course the "."-separator was just an arbitrary decision and could easily be
> changed to anything (i was thinking of "::" but "/" might do as well)
>
> everything was transparent to the user, as the original name was kept too.
> so after loading (e.g.) Gem, there was an object with 2 names (primary)
> "Gem.scale" and (alias) "scale". after loading cyclone there was an additional
> "cyclone.scale".
>
> this has been rejected.
>
>
> >
> > markex version you type markex/counter.
>
> the problem arises with multi-named libaries: if i can load Gem both with "-lib
> Gem" and "-lib gem" (eg. under windos) the scale object will either be called
> [Gem.scale] or [gem.scale]. this makes patches non-portable.
>
> however, last time we discussed this, there was an idea to introduce
> library-aliases - either at the command line or at run-time.
> probably something like "pd -lib cyclone=cyc:zexy:iemlib1=iem:iemlib2=iem"
>
>
> > So there are issues with this method but I think it has potential.
> > Obviously it could use development but I think the concept has some
> > validity. In a way this is creating a seperate namspace for each set of
> >
> > abstractions/externals. They could also be multiple levels deep:
> >
> > cvs/markex/counter
> > cvs/cyclone/counter
> > markex/counter
> > cyclone/counter
>
> could be solved by aliases too:
> "pd -lib /usr/lib/pd/extra/marke=markex:~/cvs/markex/markex=cvs/markex"
>
> as i remember now, the problem with my automatic namespacing was, that calling
> "pd -lib zexy" and "pd -lib ./zexy" resulted in 2 separate namespaces, e.g
> [zexy/z~] and [./zexy/z~] which produced non-portable patches.
> but this could be avoided with aliasing.
>
> >
> > Just throught I would throw it out there as fast as it popped into my
> > brain.
> >
> > Any comments?
> >
>
> mfg.as.dr
> IOhannes
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>