On Wed, 23 Nov 2005, Krzysztof Czaja wrote:
. define struct _libentry {t_symbol *le_name; t_libentry *le_next};
Why should new C-based components still use linked lists instead of some other data structure?
. add new member "t_libentry *gl_liblist" to struct _glist; . inherit parent's library list when creating child canvases;
How do you ever get to deallocate t_libentry ?
(also, if there is no reference-counter then you can't share portions of the liblist among several patchers and so there's no point in making it a linked list either. you have to copy the liblist every time)
. duplicate (for speed) the main loop in pd_typedmess() for the special case of pd_objectmaker target, for which the test for a method name would be extended with current glist's library list traversal; other targets ignore the me_libname member;
Wouldn't it be interesting to implement a kind of delegation or inheritance directly in Pd's core in a way that a special case wouldn't be needed?
. in canvas_saveto() run the gobj_save() loop in two passes: first for objects of well-known classes (declarations), like "using", second for the rest;
The order of objects in a glist is important, as this is what is used to generate "#X connect" lines. Do you really mean to save [using] decls first?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada