Use of Boost library classes in kdecore?

[Thiago Macieira]

David Jarvie wrote:
>> And why can't all of these different backend implementations be
>> completely internal to KTimeZone? Move them all up into kdecore and
>> flatten the hierarchy: the only publicly visible class is KTimeZone.
>
>It needs to be possible for further time zone data formats to be handled
> in the future without amending kdelibs. We can't say that we have
> implemented all the formats which will ever occur yet. And it's always
> possible that some individual application might have special data
> requirements and need to implement its own class. So it needs to be
> possible to derive new classes or create new backends, and to create
> extra methods to access data format-specific information.

The same argument could be used for a lot of other current Qt/KDE 
frameworks. But I don't think it's a strong argument.

How *likely* is it that any application will have an incredible need for a 
new technology in a 6-month timeframe (I.e., before the next kdelibs 
release)?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070708/7f81e6c0/attachment.sig>