[mcclim-devel] McCLIM 2.0 in 2008

[Robert Strandh]

Troels Henriksen writes:
 > >   * Add signed-and-dated comments to difficult passages whenever
 > >     reasonable.
 > 
 > I'm not sure I like this. I much prefer relying on the version control
 > system to provide me with this kind of information.

Although I agree that the information about who wrote a comment and
when is indeed available through the version control system, it is not
necessarily very convenient to get to.  Either way, my remark was more
about the comment itself than about the signature and date.


 > >   * Add references to the spec for code that implements some required
 > >     functionality.
 > 
 > Isn't this reference just the name of the function in question?

No, because unless you know all functions in the spec by heart, you
cannot know whether some code is intended to implement such a
function, or whether it is a function specific to the way it was
implemented.  The reference to the spec could take the form of a
section number.  There is something like that in regions.lisp. 

 > > It is hard to tell what is missing because some parts of the spec are
 > > optional, such as color blending for instance.
 > 
 > I don't think it is necessary for us to implement all optional parts
 > before a stable release.

I agree, but we must decide what optional parts should be included.

 > > But it might not be highest priority to implement all of the spec.  I
 > > would say it is more urgent to make the parts that are currently
 > > implemented work according to the spec.  I am thinking of
 > > things like output-record inheriting from standard-rectangle and then
 > > assuming all output records do so.  
 > 
 > I think it's very important to have a full implementation of the
 > non-optional parts of the spec in a stable release, otherwise it has
 > no meaning.

Of course, but I think the easiest way to get there is to make sure
the parts we have work first of all. 

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