[PD-dev] "modular" compositions of object classes

[mescalinum at gmail.com]

Roman Haefeli wrote:
> On Sun, 2009-09-13 at 21:01 +0200, mescalinum at gmail.com wrote:
>   
>> hi all,
>>
>> is it possible -in the context of writing a pd external class- to
>> invisibly patch some other object and attach to it/bind it?
>>
>> I'll try to explain better with an example:
>> if I were writing an external that is somewhat an interface to arrays
>> (read/write), I have some design choices:
>>
>> 1) copy/paste the code of array (g_array.c) (or eventually only copy
>> [tabread]/[tabwrite])
>>     pros: resulting external is tight & tidy
>>     cons: code duplication, possible breakage in future releases
>>
>> 2) provide appropriate inlets and outlets, and require the user to patch
>> the external among [tabread]/[tabwrite] objects
>>     pros: modular. is independent from the array implementation.
>>     cons: tricky to use, the user can patch it incorrectly and won't work.
>>
>> 3) is possible to patch the required objects without phisically put them
>> in the canvas [?]
>>     pros: all pros mentioned in 1) and 2)
>>     cons: [?]
>>
>> obviously, 1) and 2) are ugly under some point of view; what I am
>> interested in is 3), hence asking here if possible, and directions on
>> how to proceed.
>>     
>
> i cannot give any technical help, but from a strict pd _user_ point of
> view, i like the 2) approach the most, simply because it is so easy to
> turn what you want into an abstraction. would there be a reason not to
> do so?
>   

there are things you can't do with abstractions (have variable number of
iolets, accepting variable-type arguments, just to name some)

-- 
Federico Ferri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20090921/f18a4fad/attachment.pgp>