Wait, you support type inference and not dot imports... I think you should revisit this opinion... also, dot imports are very versatile when changing the implementation without changing a lot of LOC.
I think the string method is certainly more useful when dealing with external systems or files and constants. I think the scaled ctor is a fine addition though. > On Nov 29, 2018, at 7:56 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Thu, Nov 29, 2018 at 2:41 PM Robert Engels <reng...@ix.netcom.com> wrote: > > > > Ah, you want a ctor that is the int value. Ok. The Raw doesn’t do this > > anyway... I could add a NewI() ctor but I’m not sure it is much that > > NewF(float64(x)) given the magnitude restrictions. > > The OP says: "For those interesting in financial apps, ...". I don't think > financial apps prefer using inexact floating point numbers like float64. They > tend to rather use _exact_ values like 1234.56. Note that many such values > cannot be constructed _exactly_ from a float64 at all. Probably forces the > user to workaround using strings. Much more effective would be x := > fixed.New(123456).Div(scale), where var scale = fixed.New(100) performed > probably in init(). Or even NewScaled(int64, int64). Or even New just should > have two int64 parameters. Provided we really talk about financial computing. > > > If you review the gotrader you’ll see that it uses a dot import on this. > > Dot imports shall not pass my review. > > > If it was just Number you lose a lot of information. > > And that's exactly why dot imports should not ne used. > > -- > -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.
