On Tue, 3 Oct 2006, Frank Barknecht wrote:
To those who program with text based languages: subpatches are code blocks, they are the "{...}" in Perl or C or the indented blocks in Python.
Yes; however, not all code blocks map to subpatches: most just map to patterns of wires.
Abstractions however are functions. They are the "func" in the "int func(arg){}" of C or in the "def func(arg):..." of Python.
They're more like objects, because they have state that survive the handling of a message; and because they have instances. (Some functions called "closures" have both of those characteristics, but they don't exist in C/C++ nor Python)
IMO one should not try to dumb down a "func(arg)" into a "{}" at all.
BTW, in several popular languages, the "{}" do introduce closures: in Perl (only when preceded by "sub"), and in Ruby (in all cases). I'm not sure about SuperCollider but I'd assume that it's mostly as in Ruby.
We would probably need to create a way to declare and define an embedded abstraction in one place of the patch, maybe using a subpatch-like object [def myEmbeddedAbstraction args]
I suggested [class myEmbeddedAbstraction] in the previous mail. The "args" part is unneeded for the reason that all normal info about args is already inside of that abstraction.
But I guess that this is as tricky to implement as the [import] object that was discussed recently on pd-dev. But maybe it isn't.
two words: multiple objectmakers. This simplifies both problems into just one problem by inserting an intermediate between the imports and the "physical representation" of the involved patches. Ok, it doesn't make it "just one problem" (depending on the way you look at it), but it's still simpler overall.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada