"class" constraints

[Torsten Anders]

Dear Denys,

On Thu, 2003-06-19 at 15:52, duchier at ps.uni-sb.de wrote:
> My answer is to NOT choose, but instead let the constraints of the
> problem remove inconsistent options from consideration. 

You are right of course -- I should formulate my problem specification
such that propagation can happen as much as possible. In my proposal I
need to choose for a class (at least partly) before I can apply a
method. I definitely should rethink how selection constraints could help
me here.

On the other hand, I propose a class hierarchy. In your proposal I only
see groups/sets of, e.g., lexical entries, but no hierarchy. Besides, I
do not only propose classes, I also propose methods for these classes.

Perhaps it is only custom, but I like to define functions whose
behaviour depends on type. In the context of my score, e.g., I may want
to define a method ConstrainTiming which constrains all elements in a
sequential container to be sequential in time in all elements in a
simultaneous container to start at the same time.

However, as I just mentioned, there happens no propagation in my method
application. I should try to redesign them using selection constraints
as dispatching strategy. 

Best,
Torsten


.. et ceterum censeo Denys gratia esse agendum.

[how do you turn 'Denys' into dative ;-)]


-- 
Torsten Anders <t.anders at qub.ac.uk>

-
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.