|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2006-10-18 20:01:35
Lubomir Bourdev wrote:
> Hi Joel,
>
> Thanks for the time you spent reviewing GIL and for your vote!
>
> The AGG integration example is certainly very interesting, and we will
> add it to the list of GIL example files.
> Thanks for doing all this proof-of-concept work!
>
> The Fusion integration is a neat idea and I see no immediate obstacles
> to doing this. The less code in GIL, the better :-)
> Let's discuss details off-line.
Definitely! I'd be glad to help.
>>> - What is your evaluation of the implementation?
>> B+. I thought I'd give some negative marks here because I was not
>> able to see any regression tests, but Lubomir quickly pointed
>> out that there are some in the ASL repository. Indeed there are tests.
>> However, I give this a B+ because the tests are not extensive
>> and do not cover a lot. I see only 6 tests. A lot more work
>> should be invested in this area.
>
> I am not sure if you found the regression tests.
>
> Our regression suite is fairly extensive, though the code is not very
[...]
I see. Oh, pardon me then. Can you guys make that public and
easily accessible? I don't think I am the only one who looks at
regression tests first and foremost? Regressions plus examples
speak volumes! If only GIL was presented in the canonical
boost directory structure, then, this wouldn't have been a
problem. I suggest that future review managers require this
prior to review to avoid any confusion.
Anyway, I stick to the grade because (I forgot to mention) the
lack of examples too. To me, examples by themselves, speak volumes.
> I feel that if we hadn't provided Doxygen documentation at all we would
> have gotten higher reviews on documentation :-)
> The Doxygen documentation is not even required part of the submission,
> so it comes extra...
I disagree. The reference docs is a crucial part of the docs, as
do concept docs and tutorials. I know. I've been criticized in the
past for that (i.e. spirit). Hence, with Fusion comes extensive STL
style reference docs. That too has not been without criticisms.
Documentation is an art that I am still trying to learn.
> Those concepts are described better in the design guide.
>
>>> - What is your evaluation of the potential usefulness of
>> the library?
>>
>> Oh man, do I have to answer this? :-)
>
> Well, a few people like Jose and Rasmus were not quite convinced, so a
> straight answer would be nice, though you implied one.
Hmmm... Ok, for the record: I find GIL to be a very useful library.
I like its modularity among all its traits. GILs granularity and
modularity hits a sweet spot that makes it extremely useful for
integration with other libraries and even, I dare to say, as a core
of many graphics libraries. It is extremely flexible, extensible
and adaptable.
As far as the design and implementation of the library goes, it's A+.
No doubt about that. And to me, that's what matters most. All the
talk about comparing GIL to other libraries is constructive, to say
the least, but should not be a factor for rejecting the library.
IMO. There's some precedent already in boost where multiple
overlapping libraries were accepted (i.e. regex, xpressive and
spirit).
> Thanks again for the extensive work you put in this review!
Most welcome! I enjoyed GIL.
Regards,
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk