[mcclim-devel] One char patch to presentation-defs [really future of McCLIM]

[Robert Strandh]

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.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------