self-modifying abstractions

[pix]

well if you can imagine an abstraction with a lot of complicated logic
wrapping around some object, but that object could possibly be exchanged
with other objects to change the behaviour in some interesting way, then
this becomes handy.

if you wanted to do this "in the main window" you would have to duplicate
all of this logic.

but anyhow, everything you can do in an abstraction can always just be
done in the main window, the idea of an abstraction is to make it
easier/neater.

like procedural programming.. you don't always make functions/procedures
because they are _necessary_, they are also a conceptual aid... they
_abstract_ over details which are not immediately necessary.

i think i'm breaking some kind of rule by talking about style so close to
talk about self modifying code :)

pix.

On Tue, 25 Sep 2001 13:42:32 +0200
Krzysztof Czaja <czaja at chopin.edu.pl> wrote:

> pix wrote:
> > 
> hi,
> 
> but then, do you really need to wrap those sub-abstractions?
>
> I mean, instead of using [selfmodif blah] and [selfmodif ding]
> (where selfmodif.pd wrapper contains a [$1] object) maybe it would
> be easier to use just [blah] and [ding] in the main window?
> 
> Btw. putting [$1] object in a window is possible, and it will be
> saved as "#X obj <x> <y> \$1" -- no need to hack the .pd file.
> 
> Krzysztof
> 
> > another self reply... 
> > [...] i realised that by
> > manually editing the name of an object in the .pd file to be (for
> example)
> > "\$1", then you can change the name of that object using a parameter
> to
> > the abstraction (as long as it has the same configuration of in's and
> > out's). with some craftily designed sub-abstractions you can use this
> to
> > reconfigure the abstraction at creation time.