What's wrong with having a declare with a local scope? To have functional namespaces that encourage encapsulation, there needs to be at minimum two options: a global space and a completely local space. Then other levels could be added as desired. Currently, there is a global and a middle level, but no completely local.
That means that an abstraction could break depending on which parent patch it is used in. .hc On Nov 5, 2008, at 3:22 PM, Miller Puckette wrote: > Followup: it looks like currently, "declaring" a path inside an > abstraction adds the declaration, buggily, to the whole line of parent > patches. one result of this is that, if you have a bunch of copies of > an abstraction "declaring" a path, it actually gets searched over and > over again every time a file is opened. So I really need to fix > this... > meantime, if you're putting "declares" in an abstraction, you might > be making load times grow very high. > > I still suggest never putting declares insige abstractions, since > nobody has > yet proposed a situation in which it's a good idea, and now it > appears to > be very bad for performance. > > cheers > Miller > > On Wed, Nov 05, 2008 at 12:06:00AM +0100, Roman Haefeli wrote: >> hi all >> >> i made some tests with the new [declare] in 0.42.0test5. here the >> results: >> >> -lib and -stdlib: >> those expand the global namespace. when having [declare -stdlib >> extra/zexy] somewhere, all zexy classes are available for any >> patches. >> >> -path and -stdpath: >> they expand the namespace of the parent patch and all its (the >> parents) >> children patches, children's children inclusive. to be more clear: a >> [declare] in abstraction [foo] expands the namespace of abstraction >> [bar], when both are instantiated in the same patch. also the parent >> patch's namespace is expanded, but not the parent's of the parent. >> other patches with no relationship are not affected at all by - >> path and >> -stdpath. >> >> this behaviour differs quite significantly from the >> implementations of >> declare in previous pd versions. also, unlike announced, it is _not_ >> disabled within abstractions. personally, i think, that is the best >> [declare] implementation that we ever had. i think, it covers many of >> the use cases one can think of, also because it affects the parent >> patch. because all of that, i really hope, that the declare's >> 'philosophy' won't change too much in the future. out of curiosity >> and >> out of the need of a reliable behaviour: what are the future plans >> for >> [declare]? will it basically stay as it is (which i personally hope)? >> >> roman >> >> >> >> >> >> >> ___________________________________________________________ >> Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! >> Mail: http://mail.yahoo.de >> >> > >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev ------------------------------------------------------------------------ ---- There is no way to peace, peace is the way. -A.J. Muste _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev