[PD-dev] declarations

Krzysztof Czaja czaja at chopin.edu.pl
Mon Mar 7 18:27:50 CET 2005


Here is the promised proposal.  It is about persistent,
abstraction-scoped class name resolution.

1. There is an internal class 'declare', instantiated in several
forms.  One form is [declare compatibility ...], another is
[declare requirement ...], etc.  Shortcuts may be provided for
convenience.

2. Any [declare] object is automatically sorted up to the head of
a glist.

3. An object [declare requirement library this that] checks if
libraries 'this' and 'that' are already loaded.  If they are not,
an attempt is made, and any failure reported.  This simple
behaviour might be further extended with version checking and
auto-downloading.  When these features are supported, they might
be applicable to other dependencies as well: sound files,
abstractions, etc.

4. An object [declare compatibility this that] registers symbols
'this' and 'that' as a compatibility declaration, which is active
for its containing patch and all subpatches.

5. For any class name N and constructor C, it is possible to
specify, that if N is multiply defined, C is not to be called,
unless a particular symbol or symbols are compatibility-declared
for an object's containing patch.  If an active declaration
matches, C overrides other candidates.  Which could be implemented
by:

6. Setting a callback during class definition.  The callback,
stored in an extended t_methodentry structure, would take as
arguments all active compatibility declarations concatenated, and
it would return an index of the first required symbol found there,
or -1 if nothing is found.

7. Pd keeping track of name clashes, and prior to creating an
ambiguous object, invoking the callbacks of all candidates.  The
constructor with the lowest nonnegative return wins.  If all
returns are negative, a constructor with no callback set wins.
Everything else is undefined.

Krzysztof




More information about the Pd-dev mailing list