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

List:       koffice-devel
Subject:    Re: KSpread 2.0: some issues
From:       "Tomas Mecir" <mecirt () gmail ! com>
Date:       2006-12-25 9:21:09
Message-ID: 492258b10612250121v7a372e75s1c22568fa39587ef () mail ! gmail ! com
[Download RAW message or body]

2006/12/24, Ariya Hidayat <ariya@kde.org>:
> and for function "bar" which works with either floating-point or
> complex number, it will be different, i.e. just convert all parameters
> to Complex:

Hmm. Yes, this can work, on the assumption that:
1. we don't mind hardcoding Float initially, then rewriting relevant
functions to Complex, or start with having both Float and Complex
right off
and
2. we don't mind having to modify each function IF someone really
writes that quaternion class, or something like that. Is this an issue
? At the moment, I do not see the need for anything other besided real
numbers and complex ones, so with current state of things it's safe to
proceed that way, but it might cause problems if we do see a reason to
add a new datatype in the future. The whole point of ValueCalc is to
provide an abstraction for datatypes, so that when we add a new one,
only ValueCalc needs to change to get all the functions to work again.

/ Tomas
_______________________________________________
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]