[PD] nosferatu namespaces

Mathieu Bouchard matju at artengine.ca
Sat Nov 26 18:54:38 CET 2005

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 

> . 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 

Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
Freelance Digital Arts Engineer, Montréal QC Canada

More information about the Pd-list mailing list