thanks for the interest, a Done method would be what i was thinking of by the type/object way to do it, rather than the closure way of handing-back/defering a func.
but its the isolation i'm thinking about, without some way to get the garbage collector to call code,( like in the original post using a defer effectively would have to have been doing, which seemed to me to be nice and neat ), you always end up polluting the calling code. when using an unoptimised version, or optimised one way, you would generally need modification to the calling code to be able to switch to some other way, leaking the solution. unless, that is, you always call a Done/destructor from the calling code, and have a dummy method on the unoptimised version, which seems to be the best you can achieve. i guess this at least would be performant, given the compiler should short-cut such a call. but for now i'm looking at other, non-registry ideas, but it seems to me this is fundamentally not optimal. BTW i went with the closure solution simply based on the inability to store functions, matches the transitory nature of a global state/history/environment based optimisation. also i think these are the types of optimisation to be thinking about because they aren't going to matched by any compiler. -- 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.
