[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KSpread: Number class - some issues
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2007-05-27 18:34:22
Message-ID: 200705272034.25745.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 27 May 2007 19:00:25 Tomas Mecir wrote:
> Yes, I am aware of that. And I would like to change this, if possible,
> to achieve greater flexibility. Because flexibility is good.
>
> So, would the following approach be acceptable for you ?
>
> - the Number class gets written the way I proposed, with complex
> numbers included
> - there is a typedef Number double possible
> - if the abovementioned typedef is not used, then complex numbers (and
> high-precision ones, once they get supported) will be handled by the
> Number class
> - if the typedef does get used, complex number support will get
> #ifdef-ed into the Value class
> - the IMFOO functions will be capable of using both approaches with
> #ifdef (they're both simple - one or two line of code, so it's not a
> problem)
>
> This way, we get both high speed when the class is not included, and
> greater flexibility (all functions supporting complex/high-prec
> numbers, and such) when it is included.

I am not convinced, because this sounds overly complex to me. What kind of 
greater flexibility do we get compared to the approach I explained?

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]