[PD] Zen Garden re-implementing the wheel in C++?
matju at artengine.ca
Sat Apr 17 19:49:03 CEST 2010
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
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
> 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++
> 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
> 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
> (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
More information about the Pd-list