[mcclim-devel] One char patch to presentation-defs

[Robert Strandh]

rpgoldman at real-time.com writes:
 >     RS> Also, like I have said many times, McCLIM needs a near-total overhaul
 >     RS> in terms of code maintainability and compliance with the standard.  So
 >     RS> if I were to take ownership, I would not start by fixing immediate
 >     RS> problems, but by improving the code in order to make such fixes
 >     RS> easier.  We are talking at least a few months of work I would
 >     RS> think.
 > 
 > Suggestion:  if we decide to do such a thing, would it be possible to
 > do another code freeze and "stable" release in the meantime?  
 > 
 > Esp. if we'd like to get more users, it might be nice for us to have a
 > version that was easy to grab (asdf-install?), and about which
 > programmers could develop an oral tradition involving limitations,
 > workarounds, etc.

I guess so.  Though, a "near-total overhaul" could still be
incremental, or that's the way I would do it anyway. 

 >     RS> The second meaning is an application that is uniquely hackable because
 >     RS> it is written in CL and would therefore attract CL developers who
 >     RS> would be willing to put up with fewer features than what some similar
 >     RS> existing application have, in return for easily being able to add
 >     RS> their own features.  Closure and Climacs are such
 >     RS> applications.
 > 
 > I don't mean to carp, but it's hard to see Climacs as such an
 > application because Emacs (resp Xemacs) are already so extensible and

I might be wrong of course, but my bet is that when it comes to CL
development, extending Emacs or Xemacs will be much harder because of
the need to communicate with CL over byte streams. 

 > they suck up much of the available extension energy.

perhaps this is a sign that they are not easy enough to extend :-)

-- 
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.
---------------------------------------------------------------------