<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>