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