to abstract OOP

[Torsten Anders]

Hey, this mailing list is incredibly fast responding, thanks!

On Friday, May 16, 2003, at 01:35  pm, Denys Duchier wrote:
> t.anders at qub.ac.uk (Torsten Anders) writes:
>> So, now I only aim for reflection writing the class hierarchy.
> Ok, but why?  is this purely an intellectual exercise (no problem, I
> can relate to that :-)?

Dear Denys,

To be honest, I am not quite sure for myself how much information I 
_really_ need in the end ;-) I just sketch my project, perhaps there is a 
more strait-forward
way do to it.

I am going to use the constraint programming capabilities of Oz for 
computer aided music composition. During the composition process I create 
a music score. Currently, I am defining the data structure for that score.
  In a music score you find lots and lots of different forms of data. 
Actually, there can be no finite number of score data types, because for 
every new composition a composer might come up with new ones...

Therefore, I want to do the score data structure in a rather general way. I 
also want to be able to express/extract as much information as possible in/
from the score. I plan to organize the data structure definition in an 
hierarchic way (using OOP). My current sketch consists of about 15 
_abstract_ classes, and an average hierarchy depth of 4 super classes for 
the leaves in the 'abstract-classes-hierarchy'. This leaves will be further 
specialized for lots of user-classes, possibly by the user himself.

OK, why do I want to use reflective OOP? I my view, class-membership is 
just a further datum in the score. Some arbitrary musical note shall not 
only 'know' its pitch, which voice it belongs to etc. The note shall also 
know that it is a note (with this and this parameters), which is a 
timedElement, which is a... Who knows in what situation this informations 
will turn out useful later on, you never know ;-) If I can make this info 
accessible, I will do it.

But this information may also turn out to be useful for the implementation 
of the data type hierarchy itself. I planned to use the reflective 
capabilities to implement type checking (e.g. the function IsTimedElement 
shall return true for a note, because the class TimedElement is a super 
class of the class Note). Unfortunately, I can not do type checking by some 
simple method in the class, which always returns true and by the same 
method in the top super class, which always returns false -- if some user 
later wants to add some subclass, he would must extend the top class, which 
I try to avoid.

Best, and thanks again for your response,
Torsten

-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.
Please send bug reports to bugs at mozart-oz.org.