hi, happy it helped!
On Thursday, May 4, 2017 at 10:13:42 AM UTC+2, Ben Davies wrote: > > Interesting stuff! Thanks for the pointer on > https://github.com/mh-cbon/mutexer > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmh-cbon%2Fmutexer&sa=D&sntz=1&usg=AFQjCNGx6jkyGN5ft0dHpV_znYMkCSi5KQ>, > > missed that! I have noticed that the https://github.com/mh-cbon/mutexer > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmh-cbon%2Fmutexer&sa=D&sntz=1&usg=AFQjCNGx6jkyGN5ft0dHpV_znYMkCSi5KQ> > version > doesnt implement all the methods the lister does (such as map, filter). > > Yes, the demo code is a bit outdated, moving quickly on it. It will update (automatically) on next release. The mutexer / channeler unlike the lister /plumber are made to dig the input type and reproduce its methods. So that should work fine, unless you get caught by uncovered cases, and there are some definitely (likely gonna have pb if you have a channel params, as an example). Hope you ll issue/pr that if you stubble on it, they really are small problems to cover. > I was thinking of doing something similar myself for iterator types e.g. > Next(), Rewind() etc. > > Sure yes. Im not a purist of the computer science, I just did what worked and needed for me. What s cool with that generator idea, is that if you make a generator based on the work i presented, anybody can re use it and combine its types in a glance! I really love it, there no performance penalties related to reflection, its way easier to understand than generics, and covers much more than this last thing. (imho generic are a subset of generators, stucked into a complex paradigm of type to handle, but its another topic) Though, this is all quiet new for me, so there are situations and difficulties to uncover (like what would be the right way to magically log?) > Might have a play with a fork of Lister and see if I can get a version > working. > > would be cool :) > Incidentally, out of curiosity, I noticed that the output code is "hard > coded" into the main.go; would it not be clearer/more maintainable to use > templates? > > Yes, if one can define an API to deal with the AST and the types. It s not a simple topic at all, in fact i already tried this approach but, at that moment, i abandoned because its too complex and heavy for myself, and i was inventing new language, which i want not. See this example, https://github.com/mh-cbon/gigo/blob/master/demo.gigo.go which aims to generate a typed slice with its mutex facade. Its +/- ok, but that other example that should reproduce the chan facade, starts to get slightly more complex (error prone) for templating https://github.com/mh-cbon/gigo/blob/master/chanmux.gigo.go Just so you know my next steps are - a generator for the RPC-JSON client, the inverse of jsoner. - a begin of database handling on top of what i presented so far > On Wednesday, May 3, 2017 at 4:37:42 PM UTC+1, mhh...@gmail.com wrote: >> >> hi >> >> > Can anyone else recommend any other generators that produce >> lists/iterators like this? >> >> good Q. >> >> > Is the resulting generated code safe to use from multiple go routines? >> >> The slice itself nop, because, for that you want to use >> >> https://github.com/mh-cbon/channeler >> or >> https://github.com/mh-cbon/mutexer >> >> You make a typed slice then you facade it with one of the syncer. >> >> So yep, that example is not TS, >> this was just for fun and demo >> >> backend := NewTomates() // This is not TS, it d need an additional >> layer >> backend.Push(Tomate{Name: "red"}) >> jsoner := NewJSONTomates(backend) >> httper := NewHTTPTomates(jsoner) >> >> // public views >> http.HandleFunc("/", httper.At) >> >> /* >> curl -H "Accept: application/json" -H "Content-type: >> application/json" -X POST -d ' {"i":0}' http://localhost:8080/ >> */ >> >> log.Fatal(http.ListenAndServe(":8080", nil)) >> >> >> In the same manner if you have n collections in memory which needs TS, >> that d be inappropriate to have n TS lists communicating with each other >> on the main routine, >> that d create additional contentions, >> you d better create a controller, that is totally TS, >> that access those slice without syncing. >> >> >> On Wednesday, May 3, 2017 at 4:30:20 PM UTC+2, Ben Davies wrote: >>> >>> Is the resulting generated code safe to use from multiple go routines? >>> >>> On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote: >>>> >>>> Hi, >>>> >>>> several generators i made to avoid some duplication. >>>> >>>> https://github.com/mh-cbon/lister >>>> >>>> Package lister is a generator to generate typed slice. >>>> >>>> >>>> https://github.com/mh-cbon/channeler >>>> >>>> Package channeler is a cli generator to generate channeled version of a >>>> type. >>>> >>>> https://github.com/mh-cbon/mutexer >>>> >>>> Package mutexer is a cli generator to generate mutexed version of a >>>> type. >>>> >>>> >>>> so basically, using below code you got hundreds of line generated for >>>> you, >>>> >>>> >>>> in that example to make a mutexed []Tomate. >>>> >>>> >>>> But as it s not too stupid, or tries too, it will be able to handle >>>> >>>> pointer and basic types >>>> >>>> mutexed []*Tomate >>>> >>>> mutexed []string >>>> >>>> ect >>>> >>>> >>>> It should also be able to lookup for a constructor of the src type >>>> (Tomate), >>>> >>>> and reproduce it into the dest type implementation. >>>> >>>> >>>> There is both mutexer / channeler because both cases applies for >>>> reasons. >>>> >>>> >>>> The lister is a convenient way to create typed slice. >>>> >>>> >>>> package demo >>>> >>>> // Tomate is about red vegetables to make famous italian food. >>>> type Tomate struct { >>>> Name string >>>> } >>>> >>>> // GetID return the ID of the Tomate. >>>> func (t Tomate) GetID() string { >>>> return t.Name >>>> } >>>> >>>> //go:generate lister vegetables_gen.go Tomate:Tomates >>>> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex >>>> >>>> hth >>>> >>>> -- 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.
