kr writes:
Robert Strandh writes:
It is a totally different project in my opinion. To improve the current code, the owner needs to know both the spec and the code. To improve the spec, only a limited amount of knowledge of the code is required.
could you please say more about which particular aspects of mcclim need to be improved in what ways ?
what is the list of the current 5 top problems that would benefit from large architectural changes ?
(i've only started listening in on this mailing list recently...)
That list is going to have to be fairly vague at the moment, because I haven't figured out in detail what the problem is:
* in several places, implementation of some part of the spec uses internal classes and/or methods that are not part of the spec in such a way that it is impossible for the user to create a spec-conforming extension that will work with this implementation. An example (until Tim Moore fixed it, though the fix seems to have some problems) was the fact the output recording protocol required a particular slot in the output record, that is not part of the spec. Thus writing your own output record was impossible.
* I have reasons to believe that the space-requirement protocol is wrong in places, but this is admittedly vague.
* there are definitely some problems with sheet transformations in combination with output recording. If you have a sheet transformation in place then the output records will end up in the wrong place.
* output recording, despite improvements by Gilbert Baumann and Tim Moore is still not good enough with respect to performance. A tree-structured output record is necessary.
That's only four points, but the first one is probably true in several different parts of McCLIM.
Hope this helps.