On Wed, Nov 5, 2008 at 1:22 PM, Miller Puckette <[EMAIL PROTECTED]> 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. Hi Miller, Isn't the benefit of declares in abstractions that you can modify the search path of just that parent abstraction and its children? If abstractionA is known to be the only one that needs the path "special-oscs/", there's no reason for abstractionB to be looking in there.
(or, perhaps you mean no one has proposed a situation in which it is a good idea, as declare is implemented currently) Best Luke > > 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 > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
