Well, what I want to be able to do is put max-compatible objects into Pd vanilla (such as gate and scale) without breaking libraries. However, I didn't realize there were libraries out there that named things the same as Pd built-ins, with the intention of not ever getting instantiated under the original name.
Maybe, if zexy/pack and zexy/unpack are only meant to be called using their "path" names, it would be better to specify them as "zexy/pack" etc. in class_new()? If it isn't possible to alias objects with external libraries, I don't see how I can ever add a class to Pd once some library appears that uses the same name. Ideas, anyone? thanks Miller On Wed, Nov 05, 2008 at 09:23:02AM +0100, IOhannes m zmoelnig wrote: > Roman Haefeli wrote: > > hm.. only now, i see that overriding built-ins seems to be intentional. > > yes, this has been calimed to be a feature: > http://lists.puredata.info/pipermail/pd-dev/2008-06/011846.html > > i still don't believe it really is. > it might be better to add an explicit way to override builtins (or > pre-loaded externals). > > > > when starting pd with loading zexy, i get: > > > > warning: class 'pack' overwritten\; old one renamed 'pack_aliased' > > warning: class 'unpack' overwritten\; old one renamed 'unpack_aliased' > > > > > > and pd's built-in [pack] can be instantiated with [pack_aliased] > > > > ????????? > > the fun starts when yet another library claims the name [pack]. > > > mfgad.sr > IOhannes > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list