hi all,
sorry for a longish post, and for dealing with what is surely not
a high priority feature... Anyway, I will gladly hear from other
devs about their views.
What I have in mind, is that during object creation, when the
requested class is not known, and there is no matching
abstraction, a `failsafe' replacement object is used. Currently
in Pd, it has never any inlets nor outlets, even if loaded from
a patch with the original object connected. (A slightly
different case, and apparently easier to deal with, is an already
patched up object, edited into a ``couldn't create'' nop by the
user.)
Currently in Max, such creatures, called `bogus' objects, do
preserve connections.
The newest cyclone's import feature creates connection-preserving
replacements of all unknowns. The implementation is pretty
straightforward:
. for every object of unknown class, create a bogus having as many
inlets and outlets, as any sane object is ever likely to have;
. then, after the entire binbuf representation of a file has been
evaluated, broadcast a request to all newly created bogus objects,
making them adjust both their ports (delete every inlet/outlet
right to the last connected one), and their text (delete the
'_port.bogus' prefix).
For details, search for 'bogus' in miXed/shared/common/port.c in
cvs.
This is simplistic, in a way, but I would rather avoid an
additional parsing pass through the binbuf, and avoid maintaining
an auxiliary data structure.
In the cyclone's case of an import-only mechanism supplied by an
external library, the tricky part is to support the actual notion
of an ``unknown class''. This is not just a class not yet
defined, but such, that is also going to fail an attempt to load
its library and abstraction files. Maintaining a specialized
replacement of the binbuf_eval() routine would have been an even
bigger evil, so I had to fake it -- by blocking all possible
library/abstraction loading attempts from within binbuf_eval(),
i.e. by temporary marking as `bogus' (during Max-to-Pd binbuf
conversion stage) all objects of not yet defined classes.
Thus, in the import-only implementation, the library/abstraction
loading attempt is always performed in the constructor of a bogus,
which, in case of a successful loading, transforms itself into
a `reclaimed' object proper. However, for every reclaimed object,
in order to get rid of a '_port.bogus' prefix, a temporary `hook'
has to be created, then invoked, and finally destroyed...
(Btw, this part could have been less clumsy, somewhat, if there
were bindlist traversal routines in the API.)
In short, it seems to work, but I have a vague feeling, that
a general mechanism would be much simpler (and more useful too).
Otoh, without more research, I have a feeling of having too narrow
a perspective for just starting to mess with Pd's way of creating
objects.
Krzysztof