On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
we've been discussing that at the LAC2008 in cologne,
back when it happened, there was no full report about it on pd-dev nor
pd-list. It was just stated that a decision had been taken. From that
point it really looked like this topic was not open for discussion. But
it's not like it looked really open for discussion ever before.
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".
This namesystem needs not be any more complex than the namesystem of pd
object classes. No-one is naming stuff like [at.iem.iemmatrix.mtx_*] nor
[at/iem/iemmatrix/mtx_*] so I don't know why you would try to make it
different for an atom-type registry. It doesn't need that disease. If you
make it look like such namespacing is the way to go.
the developer could then also provide an atom2string()-callback, that
would allow the atom_string() to make something more meaningful of the
new atom,
Yes, including saving it to a pd file, if it makes sense in such a context
([textfile] or other).
than printing "consistency check failed: atom_string" (without newline).
in the worst case (if no callback was provided),
In that case I'd like a more appropriate error message than that, such as
"unknown atom type" and/or "no way to print this type of atom"
atom_string() could at least print the atom-name, e.g. "gem_state
<at.iem.gem:state> <at.iem.gem:cache>"
more like <gemstate:083ba8c0> <gemcache:083bafe8>
it was turned down, as it adds too much complexity to the code for too
little advantages...
So how come the advantages are too little ? What are the advantages that
were actually listed ?
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
