[chuck-users] Doing something to all members of a class?
Veli-Pekka Tätilä
vtatila at mail.student.oulu.fi
Tue Mar 13 08:32:12 EDT 2007
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/
More information about the chuck-users
mailing list