[dojo-contributors] vote! vote! vote!

Revin Guillen rg at sevenite.com
Tue May 24 00:55:46 EDT 2011


At the risk of voting before the full discussion has (again?) taken place, I think I'm at:

#1: +1
#2: give each "type" an intuitive name (unlisten, etc...) and delegate or alias the final teardown process to stop() or remove(). Gives users a fairly discoverable API, but you can still write tight teardown loops.

Actually, I'm +0 on that #2. Feels kinda weak to essentially be choosing both sides at once.

--
Revin Guillen
rg at sevenite.com



On May 23, 2011, at May 23 | 9:08 PM, Kris Zyp wrote:

> #1: +1
> #2: cancel or remove
> 
> Based on this description, that the method being described is not for GC purposes, and based on the fact that our destroy methods our almost entirely built for the purpose of dealing with GC deficiencies in IE (cleaning up event handlers that would otherwise be GC'ed), it would seem nonsensical and anachronistic to continue the "destroy" legacy. Hopefully at some point in the future we won't need "destroy" at all (presumably post IE7 or IE8). On the otherhand even in world of reliable GC, we will need to remove or cancel listeners to events and promises, which is not destructive like our GC workarounds are. 
> 
> The removal of a listener from an event or promise is basically a removal of entry from a list. I don't know of any PL that calls the removal of an entry from a list "destroy". Based on the description, destroy seems to be poorly worded for the future of Dojo and completely misrepresentative of the removing a listener from an event or promise.
> 
> Thanks,
> Kris
> 
> 
> On 5/23/2011 9:02 PM, Eugene Lazutkin wrote: 
> >
> 
> 
>> During the last meeting we discussed three related naming things, and 
>> decided to vote on one of them. 
>>  
>> Short description 
>> ================ 
>>  
>> I proposed an architectural principle to follow in all new development 
>> --- use well defined objects with unified API instead of magic cookies 
>> returned by various functions. 
>>  
>> Examples of magic cookies from Dojo would be opaque values returned by 
>> dojo.connect(), dojo.subscribe(), and similar. Examples from 
>> JavaScript would be opaque values returned by setTimeout() and 
>> setInterval(). The common theme is that these values are not 
>> transparent for a user, it is impossible to tell if they are valid or 
>> not, and they carry an implicit semantic background not detectable 
>> from JavaScript --- for example, to destroy the underlying actual 
>> objects user has to pass them to special (but different functions): 
>> dojo.disconnect(), dojo.unsubscribe(), clearTimeout(), and 
>> clearInterval() respectively, and woe to user, who passed it to a 
>> wrong function. Well, in reality it may throw, or not --- nobody 
>> really knows and it is not documented anywhere. 
>>  
>> The proposed solution is to use objects with a well defined API, so we 
>> can unify our resource-handling code, and reduce number of concepts we 
>> have to remember when coding. 
>>  
>> Example in pseudo code: 
>>  
>> var link1 = dojo.on(node1, "click", cb); 
>> ... 
>> // let's pause event notifications for awhile 
>> link1.pause(); 
>> ... 
>> // let's resume the event handling again 
>> link1.resume(); 
>> ... 
>> // let's destroy the link between the source and its callback 
>> link1.destroy(); 
>> ... 
>> // let's collect such objects in an array 
>> var arr = [ 
>>   dojo.on(node1, "click", cb1), 
>>   dojo.on(node2, "click", cb2), 
>>   dojo.sub("topic1", cb3), 
>>   widget1.on("redraw", cb4), 
>>   widget2 
>> ]; 
>> ... 
>> // let pause all of them, if possible 
>> dojo.forEach(arr, function(x){ if(x.pause) x.pause(); }); 
>> ... 
>> // now let's kill all of them 
>> dojo.forEach(arr, function(x){ x.destroy(); }); 
>>  
>> The whole idea is to reduce the API's surface, and to reduce number of 
>> concepts. Additional notes: 
>>  
>> 1) Using special objects instead of magic cookies (e.g., numbers + 
>> internal structures, or arrays) is at least as fast as the old 
>> implementation, so we are covered there. 
>> 2) Just like now if we don't want to destroy link objects ever, we 
>> just "lose" them like we do now. 
>> 3) The API should include one mandatory method that indicates when 
>> called that "we are done with this resource, we are not going to use 
>> it anymore, so please stop any active processing associated with it, 
>> and destroy all dependent resources". In the example above it is named 
>> "destroy". 
>> 4) Additional methods can be provided, if it makes sense. During the 
>> meeting people settled on pause/resume pair (and probably a related 
>> isPaused() method) for event-related objects. 
>> 5) Optionally we can made objects to handle "instanceof" operator as a 
>> simple interrogation (and fast) interrogation mechanism. 
>> 6) This principle should be applied to new modules. All old modules 
>> will support the same semantics, e.g., dojo.connect() => 
>> dojo.disconnect(), and so on. 
>> 7) Examples of such objects would be events, topics, 
>> Deferred/Promise?, animations, timers, and so on. 
>>  
>> Obviously we should coordinate and make sure that semantically similar 
>> things are done the same way using the same API. 
>>  
>> QUESTION #1: do you support this general architectural principle 
>> without taking into account naming of methods? 
>> ACCEPTED ANSWER: -1, -0, 0, +0, +1. 
>>  
>> The most controversial part of the proposal proved to be the naming of 
>> that single mandatory method, which indicates that everything should 
>> be destroyed / inactive / disposable / see the rest here: 
>> http://www.youtube.com/watch?v=npjOSLCR2hE or read it here: 
>> http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm 
>>  
>> Let me repeat the idea: it indicates when called that "we are done 
>> with this resource, we are not going to use it anymore, so please stop 
>> any active processing associated with it, and destroy all dependent 
>> resources". 
>>  
>> What it is not: 
>>  
>> 1) It is not a destructor in C++ sense. 
>> 2) It is not a finalizer in Java sense. 
>> 3) It has nothing to do with GC per se, but may be used as a helper 
>> for GC. 
>> 4) It will not be used for existing 1.x facilities, only for the new 
>> stuff. 
>>  
>> QUESTION #2: what name is the most appropriate for above described 
>> functionality? 
>> ACCEPTED ANSWER: one of: 
>>  
>> 1) destroy 
>> 2) cancel 
>> 3) your very own write-in 
>>  
>> RULES: Both answers will be tallied over the coming Wednesday giving 
>> us more than 24h to vote. Simple majority in both cases settles the 
>> matter. 
>>  
>> Time to paint that damn bike shed! 
>>  
>> Cheers, 
>>  
> >
> 
> 
> 
>       > _______________________________________________
> 
> 
> 
>       > dojo-contributors mailing list
> 
> 
> 
>       > 
> dojo-contributors at mail.dojotoolkit.org
> 
> 
>       >
>       
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
>  
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



More information about the dojo-contributors mailing list