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

[Robert Strandh]

Robert Strandh writes:
 > kr writes:
 >  > 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.

As a very typical example, see my previous message where the
implementation of incremental redisplay assumes that output records
are regions, which is not the case according to the spec, although it
is the case with the McCLIM built-in output records.  So, things work
as long as only the built-in output record classes are used, but
no longer do when client code defines new output records that are not
regions. 
-- 
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.
---------------------------------------------------------------------