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.