Yes, that is the "workaround". I mean, the lack of WeakReference makes Go (when implementing this pattern) at the same level as C/C++, since I have to know when I need to "delete" the resource in order to unsubscribe the event. I will have a look at SetFinalizer though, I haven't heard of it but I literally started programming Go yesterday x'D
quinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu: > > Isn't the "Go Way" for something like this to have the listeners > explicitly unregister themselves ? > > It does make certain event listener patterns more difficult, but I don't > think it requires WeakRefs to implement. > > > -----Original Message----- > From: tgpti...@gmail.com <javascript:> > Sent: Jun 13, 2019 5:39 AM > To: golang-nuts > Subject: Re: [go-nuts] Re: weak references > > I find WeakReferences when implementing observer pattern: A service > generate events and signal listeners that the event was triggered. This > usually requires the service to have a list to all of the listeners. Now, > without weak refernece it means that any temporary listener will not be > garbage collected and thus we will have memory grow without limits, since > the listeners will not be collected as they are referenced by the service. > When it comes to this, WeakReferences are mandatory and unfortunately Go > doesn't support them :'( > > terça-feira, 5 de Março de 2013 às 23:13:05 UTC, Steve McCoy escreveu: >> >> >> >> On Tuesday, March 5, 2013 5:43:35 PM UTC-5, Jan Mercl wrote: >>> >>> On Tue, Mar 5, 2013 at 11:24 PM, Dustin Sallings <dsal...@gmail.com> >>> wrote: >>> > Strong reference: "hands off, gc" >>> > Weak reference: "0 this if no strong reference exists" >>> > Soft refernce: "0 this if no strong reference exists and we're >>> low >>> > on RAM" >>> >>> This is magic, even though feasible by the runtime. Go excels in >>> explicitness, even though that may mean more user coding. My feeling >>> is that those two approaches don't mix well, to put it mildly. >>> >>> -j >>> >> >> It's not magic; it's not as though people won't know they have an >> instance of a weak reference on their hands. >> >> Anyhow, I don't care if Go ever gets them, but there are other fun things >> that can be done with weak references that don't have anything to do with >> caches. I wrote a Java tool+package that keeps track of every object >> created while the program runs and asserts some preconditions whenever an >> object is accessed. Of course, memory would be extremely wasted if I kept >> them all in a map with strong references for the keys, so I instead used a >> WeakHashMap, allowing the garbage collector to clean things up in a typical >> fashion. Using explicit reference counting would've been painful for that. >> > -- > 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 golan...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/19d2f189-4dc6-406b-bd1e-45c1deeef054%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5f6c64a4-f45b-4547-9e14-6039b97f26cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
