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

[Veli-Pekka Tätilä]

Kassen wrote:
>> First of all, I think  the subject is slightly ambiguous. In
>> 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
> Yes, sorry, that was my oops. I meant all instances.
No prob, thinking of the attributes or data fields of a class as data 
members is probably from C++, anyway, not from Chuck or Java.

> My "member" type here came from me mucking it up with set theory
I see, well even programmers talk about members in sets, lists and 
what-ever. Though often the terms item and element are used interchangibly.

> That's what you get when your first real language was Prolog <blush>.
Hey, Prolog is cool for certain things about formal reasoning.But it is not 
at all good for sorting data efficiently, for instance.

[calling method on all instances]
>> 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
> For -say- a dozen instances I can keep track of it by hand.
Though better put them inside some data structure, in CHucK I guess that 
would be an array. That way your code which processes one element at a time, 
is not in anyway dependent on how many items you have. BEtter yet if you 
abstract getting the next item into a method call on a class called an 
iterator, you can traverse data structures totally independently of what 
datastructure is actually being used. So if you changed from a linked list 
to an array, your processing functions might not have to be modified.

>> Static functions are always called on a class, not on an object.
> turns out I can call stati functions on instances
Ah well, that's syntactic sugar then. But say in Java, some classes cannot 
be instanciated. SO for those you cannot have objects against which to call 
those methods, <smile>.

> that mean a non-static function would be just as good aside from not
> being callable on the class itself?
If it modified static data that's shared by all instances, then yes. But it 
makes more sense to say:
Person.getHeadCount()
than it would be to say:
joe.getHeadCOunt() # Supposing Joe is instance of Person and doesn't have 
multiple heads.

>> Unless yo pass in the object as a parameter
> Actually, I think that in ChucK you can pass objects as parameters,
Ah yes and that's highly useful. I should have said:
Unless object-orientation is based on the object being implicitly passed to 
a function as its first parameter. Many scripting languages transform:
object.method(params) # supposing object is instance of class
into  class.method(object, params)

>> for axample if you write a function that will do something to a filter
Exactly, this is very powerful. Calling a similarly named, and often 
similarly typed, method on different kinds of objects and them doing their 
own things is called polymorphism, fancily put.

For example, you could have a class that traverses a tree, say a folder 
tree, and then calls a particular method when it changes to a folder or 
backs up a level. By making many sub-classes that do different things in 
such circumstances you could count sizes, delete files or what-ever, just by 
plugging in an instance of some derived class in the ttree traversal 
algorithm, or in chucK, any classs that happens to have a similarly named 
method to the one being called. If your method takes something inheriting 
from the tree traversal base class as a parameter, you have a very very 
generic method for doing things on trees.

I think ChucK as many other langs let you type in
Foo f and assign f anything derived from Foo as it has the same methods as 
Foo does. This is called polymorphism in langs like Java. But if ChucK is 
duck typed, then anything whose methods are named like those of Foo, whether 
or not it inherits from Foo, could be used equally well.

I'm thinking of creating a base class for processing MIDI events which has 
methods for registering new objects. All of the registered objects will then 
be notified of new events and they must inherit from some event Observer 
class.  So they can do their own thing and you can register objects as event 
listeneres, even at runtime.

This reminds me of a heavily used object-oriented design pattern named 
observer. The article is not as good as the Gang of FOur Design Patterns 
book, but see:
http://en.wikipedia.org/wiki/Observer_pattern

[accessing instance data in a static method]
> ChucK should maybe have caught this when I tried running it
Yes, I think so, too. IT could very well be checked at compile time that is 
prior to running. But That does not work for all languages. Perl, for 
example, let's you replace functions or methods at runtime based on 
references or evaluated code, so its typing is weaker, or if you like this 
kind of thing, more dynamic. It canot be checked at runtime.

-- 
With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/