On Wed, Nov 5, 2008 at 1:22 PM, Miller Puckette mpuckett@imusic1.ucsd.edu 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