[PD] local arrays again...

[Michal Seta]

Thanks for the clarification.
Sorry for the confusion.

./MiS


On 8/16/01 5:57 AM, "Sha Xin Wei" <xinwei at 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 at 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