On Tuesday, 4 October 2016 14:11:03 UTC+3, [email protected] wrote: > > Hi! > > I m not sure to get why you say 2-4 is not worthy. > > Is it because it seems there is no generic implementation of such behavior > ? >
I've written 3-6 hot reloaders, and I've yet to stumble on a "great general purpose implementation". Which leads to costly copy pastes. > Copy-Paste in itself is not costly... the cost comes when you need to change it. > Or some side effects that may occur and which make it to difficult to > maintain to even attempt to write it ? > I don't know the kind of template render interface do I need until I have an actual working application... this means by doing upfront design I could end-up redoing lot of work... the 0,1 approach are close to zero cost in terms of effort... once I know how the design will fit together, I can replace that part with something better. The complexity with rendering comes when you start to add the current user, server time, menus, redirections, backlinks etc... so when you don't have any of those, you won't know the "best design for that situation". > > I made a new version based on your pseudo code, > https://gist.github.com/mh-cbon/9eb7701e57a8f37bb7e62647dc9726e8 > <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fmh-cbon%2F9eb7701e57a8f37bb7e62647dc9726e8&sa=D&sntz=1&usg=AFQjCNHWZyuT23O6FMT7DGofY29Yg2tT5A> > > It's too complicated for my tastes. Try this instead: https://play.golang.org/p/9r4EYNoUEH PS: use gofmt > I slightly changed it to well split checker / producer. > i have in mind sometimes soon i ll want to load some data from a storage > which is not a FS. > Sure, but at that point you might also need to change some other design as well. > I also added the notion of StrategyDeliverer, because there could be some > behaviors > to modify when an existing result become temporary invalid. > > There is no more registry shared across goroutines, > the drawback is that for each result to be produced it needs to create N > chans, N goroutines, ect. > > I don t have enough experience to say how bad this could be, > I m little worried by contentions or other side effects i m not yet aware > of > because of the previous. > > Its still a long way to go : ) > The issue is that you are building a lot of base/framework without immediate benefit. Small incremental value enhancing changes will work better... *this of course does not mean that you don't do any planning.* In the crudest sense -- it comes down to how much value can you produce in a given time... I.e. does it really matter to the end-user that your development environment is inefficient? Probably not, so there's no clear *value* doing something more complicated... Of course, when the tool is something like gohugo.io then it is useful... but such feature shouldn't be the first step that you do, because there are more valuable things that you could be doing. + Egon -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
