[haiku-development] Re: QT for R2

> sure but I don't see why we should not offer it then. I don't expect
> a rocket stable api in the end but maybe a already good api that
> could be further improved. By starting with simple classes like
> container classes this should be not too difficult, e.g. BArray,
> BHashMap should be quite similar to BList. Furthermore, there are
> enough good apis out there where a student can get inspiration from.
> From the time span this should fits nicely into GSoC so its just the
> matter of finding a good student.

First of all, I'm not sure having such classes is useful. We have the
STL that works fine, as far as I know ? I understand the need for
BString with all the encoding, copy-on-write optimization, text
formatting stuff it brings, but std::vector and std::map don't look like
they need a replacement (and we already have a BHashMap in private
namespace, BTW).

On the project idea, it also means the student would have to write a lot
of code in areas that just don't exist yet. This means a lot of
planning, and for the project to be a success I think the student should
have a fairly stable API design done before the coding period starts.
When I did the Locale Kit work, it was the case thanks to the earlier
work of the Open Tracker team, and still, 3 years later, there are a lot
of stubbed functions in that API.

A student working on fresh new code will also not get exposure to some
of the problem an Haiku developer has to work with daily: ABI stability,
non-regression testing with existing apps, and working with the build
system and existing code overall. Look at the Service Kit project: it
was 2 years ago and it is still not in the git tree!

It will also mean that actually, the mentor will have to take part in
the API design a lot, which sometimes feels annoying to the student
(particularly when he notices that what the mentor sugested actually IS
better - I've been there :)).

-- 
Adrien.

Other related posts: