[mcclim-devel] McCLIM 2.0 in 2008

[Troels Henriksen]

Robert Strandh <strandh at labri.fr> writes:

>  > I'm not saying we should slap a stable
>  > version number on the 0.9.6 release, just that I think it would be a
>  > good, and achievable, goal to release a stable version this year. What
>  > would need to be done to make this happen? Here's a preliminary list,
>  > if you feel it is incomplete, please add to it:
>
> The more general problem I see is that whenever I feel like working on
> some feature of McCLIM, I feel stymied because of the lack of
> maintainability of McCLIM.  

I don't think it's that bad, to be honest. McCLIM doesn't do too many
obscure things, except that a newcomer may be confused about where
exactly events are read (I certainly was).

>   * Remove commented-out code, or uncomment it.

Definitely, I heavily dislike commented-out code.

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

>   * Make sure McCLIM compiles with as few warnings as possible

This is a no-brainer, and I already did some work on it back in
November, I think. Most of the remaining warnings are missing
defgenerics, which is a lot of work, but not hard at all.

>   * Add references to the spec for code that implements some required
>     functionality.

Isn't this reference just the name of the function in question?

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

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

> Again, this sounds good, but that's partly because whether this is
> reasonable or not depends on what (if any) such extensions are
> selected. 

I think MCCLIM-IMAGES should at least be selected, because it's useful
and somewhat simple. I don't know what else. Perhaps Freetype should
stop being Experimental and become an Extension?

> I think we should have at least one backend that uses a single
> mirrored sheet (the graft, I suppose), so that we can test unusual
> sheet transformations and such.  The X-window-as-frame-buffer backend
> I suggested above would do that, but perhaps Gtkairo will as well. 

This is mostly related to testing, not to actual use. Thus, while it
would be useful, I don't think it is critically important to a stable
McCLIM release.

>  >      * Insert docstrings for all exported functionality. If I recall
>  >        correctly, Robert Strandh spoke with one of the original CLIM
>  >        spec authors and was told not to worry about copyright issues,
>  >        so we could just copy from there.
>
> I am starting to think that docstrings are evil (because they are
> mostly noise to the person reading the code).  I would like to discuss
> the possibility of using (SETF DOCUMENTATION) instead. 

I think they are just as useful as comments to the person reading the
code. I'm not a fan of (SETF DOCUMENTATION), as it separates the
documentation from the code, making it easier for the two to get out
of sync.

>  >      * Documentation covering CLIM itself. The spec will have to do
>  >        for now.
>
> What do you mean by this?

I don't like the CLIM spec too much, and I would like to revise it
into something that is more usable. This would probably involve more
examples and descriptions of how the functions actually behave in
McCLIM (the spec is sometimes unclear or nonsensical).

-- 
\  Troels
/\ Henriksen