[PD-dev] "object" lib

[Mathieu Bouchard]

(Part two)

On Fri, 7 Apr 2006, Chris McCormick wrote:

> What is a method in Puredata?

It's something you hear about in PureData's error messages:

  error: +: no method for 'symbol'

> I think it's best not to try and cram OOP concepts into this perfectly
> good dataflow language.

haha, it's already full of OOP concepts.

> > Even putting PureData in the dataflow category is debatable, because
> > there's too much dependency on execution order (not really because [t]
> > exists, but because [t] has to be used so often!).
> The way Pd handles execution order makes it part of a subset of dataflow
> languages that also handle execution order explicitly. If you think that
> execution order has to be handled in one certain way in all dataflow
> languages then your definition is more narrow than mine.

My definition of dataflow is rather wide, it's just that whoever does
dataflow in a compsci department thinks that Pd is disguisedly procedural.
Nevertheless when I started calling pd a "dataflow language", most nouns
and adjectives used to describe pd were essentially the same as one would
use to describe VisualBASIC. I thought that pd needed VERY MUCH to be
distinguished from VisualBASIC so I recalled reading about the "dataflow
paradigm" from a book by Raphael Finkel and thought that it was the most
fitting. At about the same time I also renamed my IRC chat channel to
#dataflow. (It's still active and has 26 pd users online right now)

But "paradigms" or language categories are a limited tool. If all 
languages fitted exactly in a category, then either every language would 
have its own category or most languages in a category would be equivalent. 
But, most of the time, the reason why we want a separate programming 
language is when it's *not* equivalent. There is conceptual innovation 
going on and a lot of it has to do with bending the categories.

I'd classify PureData as mostly dataflow but not completely unprocedural.

> I would try and find something better (just incase Miller one day
> decides to crow-bar OO proper into Pd).

In Pd's internals, every t_method is associated to a t_class, and then
every t_pd refers to a t_class. Every message gets sent to a t_pd. A t_pd
doesn't have inlets. Inlets are icing on the cake and that's why the left
inlet is so special when coding pd externals: when you talk to a left
inlet you are talking directly to an object in OOP terms, but when you
talk to a non-left inlet you go through a translator which turns a
non-left-inlet message to a left-inlet message (or to some function-call
related to the struct that has the left-inlet)

Pd doesn't have inheritance, but that doesn't prevent it from having a
hierarchy: a [bng] button is a t_bng which is an extension of t_iemgui
which is an extension of t_object which is an extension of t_gobj which is
an extension of t_pd.

At the level of methods, inheritance wasn't implemented, so Thomas Musil
hacked his own thingy so that he could reuse some code (but it's not a 
generic thing that can be transported outside of pd).

At the level of patching, inheritance can be partially replaced by deeply
nested abstractions and a lot of [route]s, though those who'd like to
implement mixins are screwed. How would you emulate virtual inheritance 
with abstractions and [route] ?

 _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada