<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 10/26/2020 10:41 PM, Nicolás Papagna Maldonado via Cuis-dev
    wrote:
    <blockquote
cite="mid:CADGn7BMfrCAyxA8xtm+XVZW_fj8GKbNZ4VpsiKjfUDKbL8Og-w@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi folks!
        <div>Hope you're doing fine :)</div>
        <div>
          <div><br>
          </div>
          <div>Just found this issue while I was trying to add a new <font
              face="monospace">Preference</font> whose value is a block.</div>
          <div>Specifically, I want users to be able to configure the
            block that should be used for opening the class finder
            (either the default one or <font face="monospace">Cuis-Finder</font>).</div>
          <div><br>
          </div>
          <div>The issue starts when <font face="monospace">Preferences>>compileAccessMethodForPreference: </font>is
            evaluated: the message <font face="monospace">storeString</font>
            is sent to the preference value (in this case a block) to
            create the code for its accessor method.</div>
          <div>Turns out that if you send <font face="monospace">storeString</font> to
            a block (say <font face="monospace">[] storeString</font>)
            the image freezes and the only way to exit is to kill the
            process.</div>
          <div><br>
          </div>
          <div>The whole thing seems to be caused by the default
            implementation that is used (<font face="monospace">Object>>storeOn:</font>)
            when the first instance variable is retrieved.</div>
          <div>I'm not sure what a custom implementation of <font
              face="monospace">BlockClosure>>storeOn: </font>or if
            it should have one at all, but if we are unable to store
            blocks into strings maybe it will be better if we fail.</div>
          <div><br>
          </div>
          <div>What are your thoughts?</div>
          <div><br>
          </div>
          <div>Cheers,</div>
          <div>Nico PM</div>
        </div>
      </div>
    </blockquote>
    <br>
    Hi Nico, Folks,<br>
    <br>
    You are lucky today! This problem is not trivial, and our friend Ken
    Dickey complained for years about not being able to store closures
    in SmartRefStreams. I finally implemented the solution about a year
    ago. So, the only thing you need is <br>
    BlockClosure >> <br>
    storeOn: aStream<br>
        aStream nextPut: $(.<br>
        self asSerializable storeOn: aStream.<br>
        aStream nextPutAll: ' asEvaluable)'<br>
    <br>
    Please try it. If this works fine for everybody, I'll push it to
    GitHub.<br>
    <br>
    BTW, you can browse SerializableBlockClosure to see how I did it. It
    took me many hours to get it right! This has many applications, for
    example, the ability to store any object (including
    SortedCollections with sortBlock, live Morphs, etc) on files or even
    the clipboard, and materializing them in a different image.<br>
    <br>
    Cheers,<br>
    <pre class="moz-signature" cols="72">-- 
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
  </body>
</html>