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