(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