[PD] overriding objects

[Mathieu Bouchard]

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