This page refers design questions that I am currently investigating.
<harmony> is an object oriented API. This means that it is easy to extend. Just add methods to classes and interfaces, right?
I am not looking at the problem from this angle. I am looking at a harder question: if somebody wanted to implement the specification while avoiding branching from the trunk, what would they do?
There two questions integral to the above:
- how to define new actions for harmony actors and other entities?
- how to define new entity categories?
Throughout the design of harmony, I have tried to defend type safety (avoid the need for casting) as much as could. Currently the discussion regarding type safety mainly relates to that regarding extensibility – yes we can subclass harmony types, but if we do this, how much type safety should we expect to retain?
Low level methods
Currently <harmony> includes a fair number of ‘low level methods’.
Notably methods that deal with sound and animation, or certain functions partaking behavior programming.
At this point, I think that low level methods should be excluded from the specification. These methods may be included in a draft specification mainly addressing ‘behavior programmers’.
From a structural point of view, event handling in <harmony> is not very well defined. While reorganizing this part isn’t hard, there are questions that need to be refined before this reorganization can become effective:
- Are qualified event objects (‘heavyweight events’) desirable? Should I normalize around heavyweight events? (probably not)
- Are qualified XXXListener interfaces (versus callbacks) ever desirable? As it is behavior programming mainly uses callbacks, which tends to produce code that is at once safer and more readable.
- The Actor class defines a number of idiosyncratic methods (reach:, idle: strike: etc…). None of these methods accept callbacks or listeners as argument. Is this right? How useful are these methods in their current form?