[PD] overriding objects

[IOhannes m zmoelnig]

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
like "ca.gridflow.grid".

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
newline).
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
little advantages...

fgvmasdf
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100615/3f0aa6f6/attachment.bin>