Thanks for the clarification. Sorry for the confusion.

./MiS

On 8/16/01 5:57 AM, "Sha Xin Wei" xinwei@lcc.gatech.edu wrote:

hi michal,

your explanantion is an explanaton not of class inheritance or of polymoprhism, but of a more traditional and universal programming language concept: scoping of variables. the scope of a variable is conventionally determined by the calling stock order of a function F, such that the variable can be read and written by functions called from inside F. if F has arguments, those arguments' values are also available to beread, of course. whether they can be modified depends on whether the arguments are passed by reference or by value to F.

your explanation is fine, except for the label "object-oriented" which may murk the discussion a little :)

cheers, xinwei

...

On 8/15/01 5:50 PM, "Yves Degoyon" degoyon@freesurf.fr wrote:

...

Still, 2 features are surprising to me :

a/

building patch = build objects + expand their arguments

not : expand (objects+arguments) + build them

rem : this would be a too severe patch.

Sorry but I don't understand what you mean.... I will take a stab at it anyways and you tell me if I'm going in the right direction:

It is a good habit, in OOP, to reuse classes/objects. PD is like an OOP environment. Like in OOP you can take existing objects and build new objects out of them (abstractions). Now, some objects don't require any creation arguments and you can feed them messages or floats or whatever to change parameters when you need them. Other objects (like tabwrite~ and tabread~ in you example) need arguments. If you're building an abstraction it's because you intend to reuse it at some point and perhaps even you will several copies of it in the same patch (program). Things like tables (arrays) and objects referring to them need unique names so by putting a variable name you ensure that by providing a unique name to each INSTANCE of your abstraction they will not get confused. So objects contained within your abstraction INHERIT the arguments (is this what you mean by "expanding" arguments?).

You will also want to use variable args in patches where you want control the creation args of objects contained within. But if you're, say, building a reverb and you have tested all parameters of delays and filters and you know what you want you can simply give them the tested parameters and, optionally, provide a way of tweeking it in real time. And that can be done through inlets and float boxes, but that's too simple :) ... And too silly, in fact. I find it efficient to communicate with my abstractions through send-receive pairs so I end up giving my receives within abstractions variable arguments so I can specify later which instance I am sending data to.

Am I making any sense?

But all this depends on what you're doing. You can put stuff into subpatches and not worry about $n crap. For some things I don't even bother making abstractions. But I do like reuse some ideas and some things I use more than once in the same patch and that's when it's worth to put it into a separate file and deal with it on that level.

Now I'm lost...

...

b/

$n means :

"nth patch argument in an object" "nth run-time incoming value in a message"

this would be clearer to me if creation arguments would be referred as "$$n" or "£n", but this would break a lot of patches, right ??

I like to think of $n as a variable... I can understand your confusion if you come from Max background where arguments and variables in messages are different. But I like the simplicity of PD in this domain (if only a variable name within an abstraction the message could also inherit the creation argument...). So a variable is a variable regardless of where you put/find it. Just keep in mind that creation arguments are inherited only by objects contained within your abstraction (which in turn is an object, too) and not the messages.

Hope this helps a bit.

./MiS

"To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "Just do it!" - NIKE "It" - Stephen King