Was very happy to find that python generator functions (super convennient stuff for processing unlimited data streams with constant RAM usage), can quite straight-forwardly be implemented in Go as well (and even benefit from multi-threading) ... so posted a quick post about it.
Python-like generator functions in Go | Samuel's Tech Blog
Bioclipse Bioinformatics BLIPKIT C C++ D Description Logic Eclipse Free Pascal GSoC2010 java Jena JPL OWL Pellet planet bioclipse PROLOG PyPy Python RDF Semantic MediaWiki semantic web SPARQL SWI-Prolog Ubuntu · more tags · Home » Blogs » Samuel Lampa's blog ...
10 plus ones
Shared publicly•View activity
View 11 previous comments
- : Nice trick! (Took me a while to see what's happening there :) )Jul 30, 2013
- super small modification to http://play.golang.org/p/HePHPvTQYTsolution -- make the shutdown happen in a defer so we guarantee it closesJul 31, 2013
- Hi, I did wonder if I could have used defer after commenting, but I was thinking of it for the close() in makeFibChan(). I’m still trying to achieve idiomatic Go so criticism is welcome. :-)
To my mind, defer is meant to decrease the cognitive load, e.g. by duly noting that the resource will be freed no matter what soon after I’ve seen it be allocated. To move the “enough!”-sending from immediately after the condition that triggers it to earlier in the code seems to tax my memory more by having me remember the defer that’s in place. If there were multiple places where it was sent then I’d agree, defer would be preferable.
Back to makeFibChan(), perhaps it shouldn’t close the channel when it’s told to stop sending; it doesn’t know if it’s been passed to anything else that may send on it. OTOH, closing allows range at line 10 of play.golang.org/p/T1mOjA1ruo, though I’d still prefer the original’s break over else. And again, the close() being right next to the condition that triggers it seems to be less to grasp than tallying a defer from earlier.
I suppose I don’t think defer always leads to clearer code. Sometimes it does, obviously, and sometimes it removes a class of error, but there are times when it seems to be an overall negative.Jul 31, 2013
- Hiyou raise a good point -- my example is actually *more* code so while for me it's less of a cognitive load I can see your point.
Really I didn't love this solution so much -- I was looking for a clever way to use runtime.SetFinalizer so when the anonymous function in makeFibChannel goes out of scope it automatically cleans up. You can actually get a finalizer attached to that function but I am too much of a go newbie and I couldn't figure out how to automagically get the finalizer method to close the channel.
What I want, I suppose, is proper destructors. I find the need use defer to close files annoying in a similar fashion -- After a type goes out of scope there should be a way to attach clean up code (IMHO)Jul 31, 2013
- Jul 31, 2013
- Actually, haven't had a single problem with the "close-channel in the generator" approach, except today, when I realized my incredible stupidity of trying to do the same with buffered channels.
Since channels where then closed before they were emptied (because of lack of synchronization), output was garbled in the most strange and subtle ways, and I stayed confused for a good couple of hours.
Buffersize = 0, though, and everything is fine again :)Aug 6, 2013