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