[PD] overriding objects
matju at artengine.ca
Tue Jun 15 16:16:26 CEST 2010
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
Ideally, Miller would fix atom_string() and I'd delete my [print]. But we
don't live in that fairyland.
> if matju used Pd's mechanics to override the class (sidenote: Pd
> provides infrastracture to override built-in classes;
Pd started providing infrastructure for overriding builtins at about the
same time as I added [print]. I did not use that infrastructure in the
overriding of [print] because it wouldn't work on older versions of pd (as
used by pd-extended). So I came up with a hack that forcibly removes the
older [print] no matter what Pd thinks of it.
> so it seems that while some consider this "bad practice", others are not
> so religious about this),
I considered it to be ok because I figured out that I would be the only
one to do so for any given class. If there started to be conflicts of
overriding (or if we were about to have conflicts of overriding) then
there would be a great incentive for talking about an actual fix to the
builtin class, or a common external that would replace both overridings at
once, or any other resolution.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
More information about the Pd-list