Adriano,
Dne 11. 06. 20 v 16:38 Adriano dos Santos Fernandes napsal(a):
2. Strange things with iUtil in FB 4.
a) Why methods getDecFloat16, getDecFloat34 and getInt128 require
iStatus parameter? I expected that these methods should be "safe" like
iMaster.getUtilInterface() and thus should not require iStatus.
Methods that appear in non first version of an interface should have the
status parameter as even if never return an error, it may be missing on
a previous interface, which is an error. More below.
Hmm, guess that it would make sense to have mandatory iStatus as first
parameter in each method (regardless it's use to report errors), in any
method added after initial 3.0 release. So there is in fact an error in
IDecFloat16/34 interfaces that should be fixed before final, as BCD
methods does not have it.
b) Is it possible to extract time/timestamp related methods from iUtil
out to separate iTimezone interface like it was done for defloat/i128
? The iUtil is a "sink" interface prone to change, which over time
would make it [a] "crowded" and [b] subject of version escalation.
If we consider whole set of functions, including ones in stable
versions, what is different here is the decfloat, not the date/time
functions. And the non-tz version are in released version already.
iUtil was "don't fit anywhere, so it goes here" mash-up interface at the
beginning. It's unfortunate it's future was not better thought out, but
we could live with the "few" methods we've got in it with initial
version. However, the "Util" name means that method list will only grow
(it would certainly not happen if it would be named iLegacy). Just in FB
4 it would grow by 16 methods (to 29 in total) if it would follow the
flat approach. Thankfully decfloat/i128 have their own interfaces that
could grow *independently* from iUtil. It would be nice if we would have
the same for datetime. Pity that it was not done initially with 4
decode/encode date/time functions, as it would become handy when
timezone functions were added. Anyway, it would be nice if FB 4 will
grow iUtil only by 4 new methods instead 9 as it is now, by moving
tz-related ones in separate interface as well (and maybe *duplicating*
the 4 ones from iUtil as well for convenience? or the without-tz type
will be deprecated eventually?).
It would be a little bit unfortunate if we will end with 50+ method
iUtil interface in FB 6, thought. You may think that huge interfaces
does not matter, and you will be certainly right that there is no real
*technical* disadvantage. But they are really inconvenient for
developers to use, i.e. to memorize and navigate the documentation and
code completion, especially if they are "mash-up" ones like iUtil.
regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
