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.
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