<br><br><div class="gmail_quote">On Mon, May 30, 2011 at 12:04 PM, Jerome Peace <span dir="ltr"><<a href="mailto:peace_the_dreamer@yahoo.com">peace_the_dreamer@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ricardo Moran,<br>
<br>
Thanks.<br>
<br>
Indeed, #decompile does what storeString should do for Block closures. At least for simple cases. Just what I was looking for.<br></blockquote><div><br></div><div>Only for closures that don't close over anything.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The hanging question is why can't #storeString do that?<br></blockquote><div><br></div><div>It could, but only for simple cases. How much does the storeString include? If the closure is on in a system method, does the storeString include that method or a reference to it? storeString handles very simple cases of self-contained data structures. Closures, by their nature (and like classes and methods, processes, etc) are (at least potentially) extremely complex objects, the serialization of which requires considerable flexibility as one would find in a powerful pickling facility (see the current discussion on FUEL). So for me the reason is that having storeOn: handle complex cases such as closures is in conflict with the desire for storeOn: to be really simple.</div>
<div><br></div><div>HTH,</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--Jerome Peace<br>
<br>
</font></blockquote></div><br>