Wrt #N struct: Data structures have three components: drawing commands, [struct] templates, and scalars. They can get loaded in any order in a running instance of Pd. Also, [struct] templates can depend on other [struct] templates. Polluting the parent with structs found inside the children guarantees that everything will load with the correct data and display properly every time, without crashing. Unfortunately this adds complexity to data structures. You now have this "shadow" struct floating around that has no fields associated with it (which itself can cause crashes). But doing it the "right way" probably involves something like higher order functions, or promises, or something else that is overkill for a feature that apparently only two people in the community use. -Jonathan
On Friday, January 15, 2016 5:25 AM, Roman Haefeli reduzent@gmail.com wrote:
Hi all
I'd like to bring it up in a separate thread. I found two cases where abstractions pollute their parent patch, if the parent patch is saved after the abstractions have been instantiated. By polluting I mean some lines are added to the patch file that actually do not belong to the parent patch.
case 1) Using a [declare -stdlib zexy] in an abstraction adds the following line in the parent:
#X declare -stdlib zexy;
Next time the parent is loaded, it secretly loads zexy.
case 2) When using data structures in abstractions, every [stuct] adds a line to the parent patch:
#N struct 1342.seg.range float posy float bgclr;
I don't know what the effect of this is. Maybe it doesn't have any effect at all, since there most likely is no template that matches the struct.
While the effects of it are more (case 1) or less (case 2) severe, it seems just not very elegant. Should/can it be fixed?
Roman
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev