I'm currently handling this in class_new, because this is where also the additional creators for abtractions and single-object-per-binary externals are added. but actually you're right: the extra creator is only registered for the "main" class name, but not for aliases added via class_addcreator. so after loading iemlib, you can do [iemlib/init] but not [iemlib/ii], while [ii] of course works.
note that this is actually also an issue with single-object-per-binaries libraries which use class_addcreator. so I agree that it would be good to handle the automatic alias creation in class_addcreator. I will have a look.
Gesendet: Sonntag, 12. Mai 2019 um 03:56 Uhr Von: "Jonathan Wilkes" jancsika@yahoo.com An: Pd-List pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: Aw: Re: [PD] Full stop '.' in class namespace
Still down in the rabbit hole-- if this is primarily to accommodate single binary externals which hold multiple classes, you might want to go ahead and handle class_addcreator. -Jonathan
On Saturday, May 11, 2019, 6:18:25 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
no, that's not the case, I just tried it. here's the relevant PR: https://github.com/pure-data/pure-data/pull/630 - feel free to test and comment!
Gesendet: Sonntag, 12. Mai 2019 um 02:35 Uhr Von: "Jonathan Wilkes" jancsika@yahoo.com An: "Alexandre Torres Porres" porres@gmail.com, "Christof Ressi" christof.ressi@gmx.at Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] Full stop '.' in class namespace
On Saturday, May 11, 2019, 4:08:45 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
"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. If a [declare -lib foo] is nested somewhere in [myAbstraction], wouldn't this algorithm erroneously add a "myAbstraction/foo" creator? -Jonathan