On Tue, 2010-07-13 at 13:18 +0200, Frank Barknecht wrote:
Hi,
On Tue, Jul 13, 2010 at 12:43:08PM +0200, Roman Haefeli wrote:
Last time I checked, [declare] indeed was working inside abstractions.
Depends on what you call "working" ...
Quoting the help file:
WARNING: you might want to avoid putting "declare" statements inside abstractions, as their effects will extend to the calling patch. As of version 0.41, "declare path" is ignored inside abstractions, although, probably unwisely, "-stdpath" takes effect (on the calling patch as well as the abstraction.)
Attached is an example showing where declare in abstractions fails: Open abstraction-help.pd, then click "abs/abstraction" to see an object not created, although it's in the [declare]ed path. Open abs/abstraction.pd directly then: now the object creates.
This is a nice example, which exposes clearly the culprits with [declare]'s current implemtentation. Thanks for sharing.
[declare] is definitely not ready for 'intra-project' usage. However, it still can be used as a replacement for the command line flags '-lib' and '-path' for system-wide installed libraries and that was the use case I initially was talking about. Instead of Pd-extended loading system-wide installed libraries per default, those also could be loaded with [declare -stdlib], respectively [declare -stdpath]. And those work also inside abstractions.
As you pointed out, [declare] still has issues. However, in the long run it'd be the preferred way to load dependencies dynamically from the patch instead of generally and automatically on start-up. Do we agree here?
Also see the source for abstraction-help.pd to spot the "#X declare"-pollution.
It was me who reported this bug back then. And it is still not fixed. http://sourceforge.net/tracker/?func=detail&aid=2251387&group_id=557...