[PD] overriding objects

[Roman Haefeli]

On Mon, 2010-06-14 at 16:41 -0400, Mathieu Bouchard wrote:
> On Fri, 11 Jun 2010, Roman Haefeli wrote:
> > On Fri, 2010-06-11 at 11:34 -0700, Kim Cascone wrote:
> >
> > I fully agree with you. I find replacing built-in vanilla object classes 
> > a rather bad habit and quite confusing. I don't see a valid reason for 
> > doing that.
> 
> I don't see a valid reason for passing A_POINTER atoms around that aren't 
> proper t_gpointer pointers, and I don't see a valid reason for [print] to 
> say "consistency check failed" when it just doesn't know an atom type, and 
> I don't see a valid reason for avoiding the addition of custom atom types 
> in 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 and 2010.
> 
>    http://lists.puredata.info/pipermail/pd-list/2002-08/007854.html
>    http://lists.puredata.info/pipermail/pd-dev/2007-06/008995.html
>    http://lists.puredata.info/pipermail/pd-dev/2008-07/012058.html
>    (and so on)
> 
> > Since one needs to load 'gridflow' anyway to use GridfFlow, why not
> > simply put a Gridflow specific print object when needed?
> 
> The goal is to replace [print]. If I just want a [print] but [print] can't 
> be customised to work with the atom type I introduce, then the built-in 
> [print] needs to be replaced. It should be as easy to understand as why we 
> shouldn't need a [printfloat] to print floats, a [printsymbol] to print 
> symbols, etc.

As I see it, fixing the original vanilla class is the only way to go.
And if the author refuses to include a patch that addresses issues with
the original class, then the only way is to add a new class (instead of
overriding it). From a moral point of view, overriding an object class
to me seems like stealing a name, that belongs to another class. It's an
uncivilized action. However, that is my personal feeling. I don't know
how much it makes sense to talk about moral implications.

Another thing is: If I understand correctly, this can be done only once.
As soon as some other library also tries to override [print], it's going
to be messy. Which [print] you finally will have, will then depend on
the order you load the libraries. So this definitely adds another (imho
unnecessary) layer of complexity. 

Also: Before this ability was added to Pd, class names were claimed by a
simple rule: First come, first serve. When you loaded Gem first, [scale]
would call Gem's scale class, no matter if you loaded maxlib or
whatsoever after. Since built-in classes can be overriden, you have to
deal with two rules at the same time. Depending on the situation,
sometimes 'first come, first serve' applies, but in other cases 'last
come, first serve'. How difficult will it be to write a patch, that
works the same in many environments? 

Another thing: If a certain class has bugs, I would like to be able to
rely on those bug. I certainly wouldn't want to be surprised to see,
that my patch is not working anymore, simply because for some reason I
did not load gridflow or zexy anymore.

In no way I can see in what way overriding object classes would add the
claimed (by IOhannes) transparency for the user.

Obviously, a lot of people (apparently also Miller himself) don't see a
problem with the ability to override internal classes. However, I guess
the fact that Pd allows to do that, doesn't invalidate my point. I still
believe it was a mis-conception to add this functionality to Pd and
wouldn't mind to see it removed.

Roman