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