Also, the most important reason against the setters - a Fixed is immutable.
> On Nov 29, 2018, at 7:00 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > Thanks for the feedback. My comments below. > >> - 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.... >> - 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. >> - 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. >> > The benchmarks: (Decimal is the shopspring library, big Int/Float are the >> > stdlib) >> >> 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. >> -- >> -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.
