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.