This is an interesting proposition. <br><br>I have wanted for a long time to reform the way we do destroy(). Specifically<br>I've wanted to go through and make a patch replacing all the <br><br> this.propX = null;<br>
<br>with<br><br> delete this.propX;<br><br>...but have sort of just never gotten around to it. <br><br>as for the proposition here, two thoughts:<br><br>1) overriding the valueOf() thing makes me a little nervous. It seems like this is the main reason for you suggesting this in the first place, and I can see how this would be handy... but my gut reaction is that having to special case our code to deal with a variable that has possibly been destroy()ed... it sounds like that's not a situation we'd ever want to be in. the response to that might be "keep on dreamin' uz, have you looked at the code lately?" and i'm happy to stomach that ;-).... but seriously, in my mind, the destroy() call in my mind should only be happenning when the variable in question is absolutely no longer needed. which to me means that there should never be code calling it at that point. maybe there are some cases i'm not thinking of (event callbacks?) but anyways, just a gut feeling. as always, more than happy to be convinced otherwise.<br>
<br>2) there is the issue here of objects-with-objects. like when you have an obj 'foo' which has a property 'bar', which is also an object. what to do in that case? do we want to make this recursive? base case (obj has no properties or typeof obj is simple base type) return, and otherwise recursively call OL.Object.destroy() on every (typeof object) property? it goes without saying how that can be a dangerous black hole. keeping it as is below, however, has the danger of orphaning (?) a bunch of memory. is there any way to satisfy both? <br>
<br>anyways, destroy() reform is a fun topic and i'd love to hear what others have to say. <br>good suggestion, tim. <br>ups,<br>e<br><br><div class="gmail_quote">On Thu, Jan 8, 2009 at 18:56, Tim Schaub <span dir="ltr"><<a href="mailto:tschaub@opengeo.org">tschaub@opengeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hey-<br>
<br>
We don't currently have a uniform way of determining if an OpenLayers<br>
object has been "destroyed". I'm wondering what people think of adding<br>
something like this:<br>
<br>
OpenLayers.Object.destroy = function(obj) {<br>
for(var prop in obj) {<br>
delete obj[prop];<br>
}<br>
obj.valueOf = function() {<br>
return false;<br>
};<br>
}<br>
<br>
Then we could use the following to decide if something has already been<br>
destroyed:<br>
<br>
obj == false // true after OpenLayers.Object.destroy(obj)<br>
<br>
Benefits:<br>
<br>
We'd have a uniform way of determining if the destroy method had been<br>
called.<br>
<br>
Drawbacks:<br>
<br>
This only works for the level of type coercion done by the equality<br>
operator. The logical not operator still considers the object truthy<br>
(so !OpenLayers.Object.destroy(obj) === false). So, we'd probably still<br>
end up doing things like this (to test undefined or destroyed):<br>
<br>
if(obj && obj != false) {...}<br>
<br>
Also, maybe we're better off checking explicitly for properties as we do<br>
currently (!obj.events etc.)<br>
<br>
Any opinions?<br>
Tim<br>
<font color="#888888"><br>
--<br>
Tim Schaub<br>
OpenGeo - <a href="http://opengeo.org" target="_blank">http://opengeo.org</a><br>
Expert service straight from the developers.<br>
_______________________________________________<br>
Dev mailing list<br>
<a href="mailto:Dev@openlayers.org">Dev@openlayers.org</a><br>
<a href="http://openlayers.org/mailman/listinfo/dev" target="_blank">http://openlayers.org/mailman/listinfo/dev</a><br>
</font></blockquote></div><br>