On Mon, 2007-05-28 at 22:42 +0200, Frank Barknecht wrote:
Hallo,
first: Maybe we should avoid the term "parent patch" for the patch, that contains the [declare] object. Generally "parent" seems to be used for specifying the parent of an abstraction as in "graph on parent". One could consider an object like [declare] to be like an abstraction and then its parent would be the patch that contains [declare]. However IMO this becomes confusing when talking about the parent of an abstraction that itself contains the [declare].
Does someone have a better term for the patch, that contains an object? Maybe the "owner" or so.
yeah, using 'parent' lead to confusions. i'll use 'owner patch' in the future.
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
what i meant to be inconsistent:
- [declare -lib somelib] makes the objects of the external 'somelib'
availabe to ALL patches, not only to the [declare]'s parent patch.
Currently it's impossible to "unload" a binary object (builtin or external) from Pd once it is loaded. Loading the wrong [counter] binary will make all your [counter] objects behave like the one loaded first. That's also why you cannot overwrite binary objects with abstractions. Just try it.
So the fact that [declare -lib somelib] acts globally actually is unavoidable and might even be considered a bug.
- [declare -path somefolder] makes the abstractions from 'somefolder'
available ONLY to the parent patch, i.e. the patch, that contains the [declare].
That's the idea IIRC: Only the "owner" should see that modified path. Unfortunatly that behaviuor is currently broken for [declare -path ...] in abstractions.
thanks for the explanations. that makes sense for me now. am i right then, that:
[declare myfolder] [myabs]
and
[myfolder/myabs]
are essentially the same thing? if yes, what is the advantage of using [declare]?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de