[PD] Zen Garden re-implementing the wheel in C++?

[Mathieu Bouchard]

On Sat, 17 Apr 2010, Spencer Russell wrote:

> Agreed that Pd's code is certainly organized in an object-oriented way, 
> and the architecture that Miller has constructed to do OOP in C is 
> extremely clever

Well, not that clever. This kind of design has been implemented quite a 
number of times by various libraries that needed to use OOP in C : Xt, Tk, 
Gtk, etc., with the difference that those implemented inheritance and Pd 
did not, and with the difference that Pd walks a linked-list to look up 
any special selector...

> On the other hand, there are structures that come for free when using a 
> language that supports real objects out of the box (such as real 
> polymorphism)

I don't know what "real objects" and "real polymorphism" mean.

It might be a difference of ontology between us...

C++ objects are as real and are as fake as anyone else's. They're just a 
lot less annoying to use (most of the time) or a lot more annoying to use 
(sometimes).

> that are difficult if not impossible to achieve in C.

Ok, you'll have to give an example of that.

> I'm not ready to make blanket statements regarding the overall 
> cleanliness of ZG vs. PD code, but there's definitely a significant 
> reduction of boilerplate necessary to create an object, which seems like 
> a step forward.

What I see is an increase of boilerplate, or at least a massive 
replacement of old boilerplate by different boilerplate. There's irony in 
things like Pd supporting default arguments and ZenGarden making you 
define two constructors instead of just "(float f=0)" as in normal C++ 
code.

> I have some concerns about the extensibility of some of ZG's current 
> architecture (the PdGraph object has a list of all the objects it 
> supports hard-coded in), but it's still a young project with the 
> architecture still somewhat in flux.

Well, what I said about the externals API is probably because I don't know 
ZenGarden enough : I looked at how builtin classes are defined and I 
assumed that there was an externals API that worked exactly the same as 
that.

> agreed, losing the rich library of Pd externals would be a huge problem,

It's not just a huge problem, it's a no-go. I developed well over a 
hundred externals and I'm not going anywhere without them. Many other 
people are dragging their own externals behind but most people are 
dragging other people's externals behind them and have become at least as 
dependent on them.

> It also seems important to note that the ZG guys aren't trying to 
> replace PD wholesale, but just to provide a separate runtime library 
> that makes Pd patches more embeddable

That's not a Pd that many people can use. I can't think of many people 
that don't use any externals. When I contributed to list-abs, it was to 
show how complicated it can be, to make something efficient without using 
any externals.

> (within other programs, on other devices). The project was started by 
> RJDJ, so I don't imagine that dynamic patching is a high priority.

what does any of it have to do with dynamic-patching ? Well, there are 
some externals that improve dynamic-patching support, but much of 
dynamic-patching tends to be done by abstractions, while externals usually 
take care of something else.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801