[PD] overriding objects
IOhannes m zmoelnig
zmoelnig at iem.at
Tue Jun 15 16:57:57 CEST 2010
On 2010-06-15 16:16, Mathieu Bouchard wrote:
> On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
>> yes, but that's the nature of Pd's development model. furthermore, in
>> reality i suspect GF's [print] to have dependencies on GF, so you
>> would be unable to run this [print] without GF installed.
> Every class in GridFlow depends on a common piece of code that
> implements a partial abstraction layer over the Pd API, involving an
> extra preprocessor pretending to be SWIG, etc. Furthermore, GF's [print]
> depends on the grid subsystem and the code of [#print] (which is only
> able to print grids).
> Ideally, Miller would fix atom_string() and I'd delete my [print]. But
> we don't live in that fairyland.
we've been discussing that at the LAC2008 in cologne, where i proposed
an "atom registry" (similar to the class_addnew() concept), where devs
could register new atom-types.
the idea was to attach a symbolic name to an atom (e.g. "float" or
"pdpackage") and in return receive a numeric id (atom.a_type), allowing
for multiple externals to use the same atom without having to hardcode
the numeric ID (assuming that symbolic names would be less susceptible
to clashes than arbitrary numbers; e.g. one could use a dns-like name
the developer could then also provide an atom2string()-callback, that
would allow the atom_string() to make something more meaningful of the
new atom, than printing "consistency check failed: atom_string" (without
in the worst case (if no callback was provided), atom_string() could at
least print the atom-name, e.g.
"gem_state <at.iem.gem:state> <at.iem.gem:cache>"
it was turned down, as it adds too much complexity to the code for too
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
More information about the Pd-list