Yes, I understand. But if I have a productive language that doesn't need me to call it better. In C/C++ it's also easy, whoever calls new should call delete, but trust me, I've had my troubles finding memory leaks in other people's code. With a large enterprise application made in Go and working with other people and observer pattern, sooner or later I will have the same trouble finding memory this "memory leak".
Obter o Outlook para Android<https://aka.ms/ghei36> ________________________________ From: Robert Engels <reng...@ix.netcom.com> Sent: Thursday, June 13, 2019 8:08:41 PM To: tgptial...@gmail.com; golang-nuts Subject: Re: [go-nuts] Re: weak references That doesn't sound right. Whatever calls 'addListener', should be calling 'removeListener' - nothing needs to be detected. -----Original Message----- From: tgptial...@gmail.com Sent: Jun 13, 2019 11:36 AM To: golang-nuts Subject: Re: [go-nuts] Re: weak references 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 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. 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<mailto: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<https://groups.google.com/d/msgid/golang-nuts/5f6c64a4-f45b-4547-9e14-6039b97f26cb%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/DB7PR01MB49682D7B8E1D01756002BC46BCEF0%40DB7PR01MB4968.eurprd01.prod.exchangelabs.com. For more options, visit https://groups.google.com/d/optout.
