Dear Denys,
On Thu, 2003-06-19 at 15:52, duchier@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@qub.ac.uk>- Please send submissions to users@mozart-oz.org and administriva mail to users-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/. Please send bug reports to bugs@mozart-oz.org.