[PD] Full stop '.' in class namespace

Christof Ressi christof.ressi at gmx.at
Sun May 12 01:06:29 CEST 2019


> I guess the issue comes when we have s single library file, where usually you can't use a namespace.
 
that's actually my biggest issue with such libraries. (luckily there are not too many of them.) it's cool that cyclone acknowledged the issue and added those additional creators.

name collisions are real: I've once had to debug a Pd patch by a friend of mine and it turned out the problem was that he used cyclone's [gate] object. unfortunately, [gate] is also part of iemlib and it works the other way round! he later added iemlib and now the "wrong" [gate] object was being used, messing up the whole patch in weird ways :-)

he could have written [cyclone/gate] to force the cyclone version, but it's not possible to force the iemlib version because it's not a single-object-binary. note that calling the namespace version will also register itself by the classname and therefore override existing classes (without namespace):
1) load iemlib and create [gate] -> iem version
2) create [cyclone/gate] -> cyclone version (obviously)
3) create another [gate] -> cyclone version

this wouldn't be a problem if iemlib would be a single-object-per-binary library or offer namespaced creators like [iemlib/gate].

but I'm wondering if loading a lib could automatically "append" the library name to the individual objects. currently, class_new automatically registers 'class_loadsym' (a symbol containing the name under which the object has been invoked) as an additional creator, but only if the last part matches the classname (e.g. "cyclone/gate" <-> "gate"). now if 'class_loadsym' *doesn't* match the classname we can assume that it's the name of a multi-object-per-binary library, prepend it to the classname and register that as an alternative creator. this means that when 'gate_setup' is called as a consequence of 'iemlib_setup', it will register as "gate" and "iemlib/gate", assuming that iemlib was loaded with [declare -lib iemlib]. note that I'm talking about the new version of iemlib, it gets quite awkward for the old one which is split between iemlib1 and iemlib2...

one question is how [declare -lib some/folder/iemlib] should be handled: register as "some/folder/iemlib/gate" or "iemlib/gate" or both (besides "gate" of course)?

I might try this out and make a PR if it seems to work as I'm imagining it.

Christof
 

Gesendet: Samstag, 11. Mai 2019 um 23:19 Uhr
Von: "Alexandre Torres Porres" <porres at gmail.com>
An: katja <katjavetter at gmail.com>
Cc: Pd-List <pd-list at lists.iem.at>
Betreff: Re: [PD] Full stop '.' in class namespace

I guess the issue comes when we have s single library file, where usually you can't use a namespace.
 
But we've dealt with this in cyclone. You can, for instance, call [cyclone/>~] and avoid clashing with zexy's - the way this is done is a bit hacky, of course... but simple, just add a new class creator
 
https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/cyclone_lib.c#L748 

Em sáb, 11 de mai de 2019 às 18:17, Alexandre Torres Porres <porres at gmail.com[mailto:porres at gmail.com]> escreveu:

  

Em sáb, 11 de mai de 2019 às 17:26, katja <katjavetter at gmail.com[mailto:katjavetter at gmail.com]> escreveu:On 5/11/19, Jonathan Wilkes via Pd-list <pd-list at lists.iem.at[mailto:pd-list at lists.iem.at]> wrote:
[...]
> 1. A cautious user will always leverage Pd's general collision avoidance by
> prefixing your library's directory
> name in the object box.

Does prefixing with libdir name avoid collision? Is it the case that
Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded
simultaneously?
 
sure!_______________________________________________ Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]





More information about the Pd-list mailing list