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.
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
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] 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@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/