[chuck-users] Doing something to all members of a class?

Kassen signal.automatique at gmail.com
Tue Mar 13 07:46:26 EDT 2007


Hi, Velli-Pekka!


 THis is based on my
> object-oriented knowledge in general and might be incorrect in the context
> of ChucK. You have been warned, <smile>.


I'll be fine <smile>



First of all, I think  the subject is slightly ambiguous. In programming
> jargon it could mean one of two things:
> Members of a class as in the data members e.g. doing something to all data
> fields of a particular object or class gloablly via reflection. OR what
> you
> ment doing something to every instance of a class.



Yes, sorry, that was my oops. I meant all instances.

So; we'd have a forest made up of lots of instances of the tree class and I
want to burn the whole thing down by expressing "every tree is on fire". My
"member" type here came from me mucking it up with set theory where such
things are very easy to express; you'd simply go "if something is a tree
then it's also on fire" and be done. That's what you get when your first
real language was Prolog <blush>.

Classes have a certain set-theory feel to me, where extending them becomes
like sub-sets. Makes sense as a mental model for creating them but clearly
less so when adressing them.


Hmm if it is their own thing, it is an instance i.e. non-static variable,
> not a class variable. A class variable is like a global variable, except
> that it is restricted in a class. In other words, all the count methods
> would modify the same variable if the variable is a static variable. This
> is
> assuming ChucK's static works like in Java, I'm not sure about that.


I think it does, at least it works like you explain here.


>
> The easiest way to do this would be to have a class method named
> resetCounter and calling it for each of the instances you have in a loop.


That's exactly what I did now. It turns out I only have 8 instances right
now so this is still very managable.


Alternatively, you could keep track of all the instances in a static array
> in the class, and then call the reset method for all the elements in the
> array. But this latter thing is more complicated and might differ garbage
> cllection, if it is based on reference counting the objects.


Yes, I see, and it would also come down to the same thing, except with
house-keeping automated. For -say- a dozen instances I can keep track of it
by hand.



>
> Static functions are always called on a class, not on an object.


Hmmmm, not nesicarily so in ChucK. It turns out I can call static functions
on instances, it's just that it doesn't make any difference from calling
them on the class itself. Probably just a syntactic convenience.

So, static functions in classes only make sense if they act on other static
members of that class and have no real other use? Wouldn't that mean a
non-static function would be just as good aside from not being callable on
the class itself?



> Unless you
> pass in the object as a parameter but that's suspicious outside of certain
> scripting languages whose names start with p, in which it is the right way
> to do it.


Actually, I think that in ChucK you can pass objects as parameters, for
axample if you write a function that will do something to a filter you can
pass it the reference to a speciffic instance as a parameter. Not so
suspicious, to me.

That is because chucK does not know hwich object's variable you are
> accessing. THink of it like this:
> If you call a non-static method, the variables you are likely to deal with
> are particular to that instance of the class, although you can access and
> modify static variables that all the instances share, too.
> If you call a static method, you are doing something global to all
> instances, such as modifying a shared static variable. AS the variable is
> shared, you don't have to have an instance to be able to refer to it.


Right, yes, I see now.

In that case; would it be at all a bad idea to make a new sort of function
that would act like I described? That sounds very usefull to me. Clearly
something functionally identical could be made but that would mean
additional structures to keep track of how many instances we have and what
they are called which might complicated matters considderably. Clearly ChucK
already has to keep track of those exact things anyway so why not make that
info available to the program se we can do things like making all instances
of the class "person" jump at the same time? Especially for things like
polyphony and particle-based synthesis techniques that would be nice.

(I'm sure I'm blundering over a lot of CS concepts right now)


> about a nullpointer exception.
> A semantic quibble, why is it called a null pointer if the language only
> supports references? I've been thinking the same about Java.


Well, that's another question... I was thinking that ChucK should maybe have
caught this when I tried running it like it did when I tried adding the
"this" keyword (at that point I still thought I could get the function to
execute for every instance in turn).



Hope this clarifies matters. IF not, I could try to demonstrate using a code
> sample.


Totally clear now, thanks!

Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070313/c50b5105/attachment-0001.htm 


More information about the chuck-users mailing list