Thank you for your response again. In the case where anonymous classes are used, the anonymous class would add it self as listeners as you said, but what happens is that the service where the listener will be added will have a weak reference to the this listener. This means that the listener can be collected anytime without calling the RemoveListener. I worked with projects which all the arquitechture was event based, and sometimes even small things like a field of a class are listening to something to keep it's value updated. Sometimes you end up with lots of listeners. Regarding this last case, imagine you have a class A that inside has a class B. Object B is listening to something but it will not be collected until object A is collected. So, Object B never really knows when he needs to stop listening. In this case I will have to come up with methods to communicate between the two objects or instead I will have to turn object A as a listener to act as a gateway to object B. This is not productive at all in these cases, that's why I like to have WeakReferences.
Obter o Outlook para Android<https://aka.ms/ghei36> ________________________________ From: Robert Engels <reng...@ix.netcom.com> Sent: Thursday, June 13, 2019 8:35:15 PM To: Ricardo Alves; tgptial...@gmail.com; golang-nuts Subject: Re: [go-nuts] Re: weak references But using weak references for listeners is fraught with problems. The most common being that listeners are often anonymous inner classes (in something like Java) or at the point instantiated (closure), so if a direct reference is not held, the listener is would be immediately removed. Holding the reference to the inner instance is cumbersome - often requiring the developer to create an instance variable and assign to that. But you still need to manage the lifecycle of the object that was listening... so why not remove the listener then. I don't think a finalizer helps in this case - since the service will have a hard reference to the listener, it will never be finalized... or GC'd, unless the removeListener is called anyway. That being said, if the service is no longer referenced, all listeners will be GC'd - there will be no memory leak. For example, Java Swing doesn't use weak listeners, but it does have weak references in some cases to the Window (i.e. Service), which contains references to all of the components (which are the listeners). When the Window goes out of scope, everything will be destroyed (cleaned up by GC). -----Original Message----- From: Ricardo Alves Sent: Jun 13, 2019 2:12 PM To: "tgptial...@gmail.com" , golang-nuts , Robert Engels Subject: Re: [go-nuts] Re: weak references 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/DB7PR01MB4968C94B65803A35CC47DD36BCEF0%40DB7PR01MB4968.eurprd01.prod.exchangelabs.com. For more options, visit https://groups.google.com/d/optout.
