On Thu, Nov 29, 2018 at 2:00 PM Robert Engels <reng...@ix.netcom.com> wrote:
>> - To me type name 'fixed.Fixed' sounds like Javaism. Go code usually
tries to avoid such stutter: 'sort.Interface', 'big.Int' etc.
> To me that’s a limitation of Go with small packages like this that only
have a single public struct. It is based on decimal.Decimal so I’m not the
only one who thinks this....
I don't think we are talking about the same thing here. Go idiom is to name
types such that they are not the same as the package qualifier (modulo
case) at the caller site. So the exported type should be 'Int', or 'Float'
or 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller
site. `var n fixed.Number` looks better to me, for example, than `var n
fixed.Fixed`. The later actually does not even communicate any hint what
the type could possibly be.
>> - A struct with a single field could be replaced by the field itself.
OTOH, it would enable coding errors by applying arithmetic operators to it
directly, so it's maybe justified in this case if that was the intention.
> It was the intention. The Raw methods are there temporarily and will be
removed for direct serialization via a Writer.
Then it looks strange that to construct a Fixed from int64 one has to write
'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) constructors and
setters, they are much more natural to use.
>> - I'd prefer a single constructor 'New(int64)' and methods 'SetString',
'SetFloat' etc.
> Not possible. The caller doesn’t know the int64 value. Also, think of how
that would look in a chained math statement. Horrible.
It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that
has the _value_ of n, which of course has a different underlying int64 bit
pattern in the private Fixed field. The caller want New(42) meaning 42 and
does not casre about the internal, scaled value, that's just an
implementation detail and no business of the caller. BTW: Chained math
statements where the operators are written as function calls, above chains
of length 2 are not seen very often. Longer ones, in many cases, well,
that's what I'd call horrible.
>> I don't consider comparing performances of 64 bit integer arithmetic and
arbitrary sized arithmetic very useful.
> Those are the alternatives to use when performing fixed place arithmetic.
In fact decimal.Decimal uses big Int... so it is included for reference.
The point being made here is fixed size fitting to a machine word on a 64
bit CPU vs arbitrary sizes math libs implemented inevitably by multiple
word structs with pointers to backing storage and the necessary allocation
overhead. Apples to oranges. Not even in the same league.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
