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