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):
- load iemlib and create [gate] -> iem version
- create [cyclone/gate] -> cyclone version (obviously)
- 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@gmail.com An: katja katjavetter@gmail.com Cc: Pd-List pd-list@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/cy...
Em sáb, 11 de mai de 2019 às 18:17, Alexandre Torres Porres <porres@gmail.com[mailto:porres@gmail.com]> escreveu:
Em sáb, 11 de mai de 2019 às 17:26, katja <katjavetter@gmail.com[mailto:katjavetter@gmail.com]> escreveu:On 5/11/19, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> wrote: [...]
- 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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]