I like the idea of having everything implemented as a loader. Then there could be something like /etc/init.d for the loaders, with the file order being the order that the loaders are run.
But I don't think I can offer much insight on this problem. .hc On Apr 19, 2007, at 8:00 AM, IOhannes m zmoelnig wrote: > hi miller, all. > > > i am currently having troubles implementing the hexloader as a > system-loader. > while things work rather straightforward in external/library land, it > stops being trivial when it comes to loading abstractions via a > system-loader. > (this is needed since the hexloader mainly applies a different > objectname<->filename mapping, which should eventually work for > abstractions too) > > the problem is, that in the context of the loader, i have no idea > about > the arguments for the object instance. > unfortunately abstractions do not have the "abstract class" vs > "instance" separation like binary objects, so the only way to > instantiate them seems to be to directly evaluate them with the > arguments available in some "context". > > ultimately it would be good if patches would be loaded with the same > mechanism as other externals within the pd core (this is: with a > separate patch_loader() that is registered just like the lib_loader()) > > > a temporary workaround would be some way to access the arguments > passed > to a yet-unknown object from within the loaders. > > > mfasd.r > IOhannes > > _______________________________________________ > PD-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev ------------------------------------------------------------------------ ---- Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
