<br><br><div class="gmail_quote">On Wed, Jul 8, 2009 at 11:13 AM, David Goehrig <span dir="ltr"><<a href="mailto:dave@nexttolast.com">dave@nexttolast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Wed, Jul 8, 2009 at 12:55 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>Well the obvious way to clean up those closures is to pass the self reference as an argument, so</div><div><br></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
(An object named: #Casper) has: #greets: of: [ :theSelf :x | Transcript show: 'Hi ', x name , '! My name is ', theSelf name; cr].</div><div></div></span></div></div></blockquote><div><br></div></div><div>
That's an even worse hack. :)</div></div></blockquote><div><br></div><div>I disagree :) Reaching into a closure's home in a completely unthread-safe manner is a horrible hack. Using closures to implement properties is an implementation detail and one is free to compile to those closures as one sees fit. Better to make the soft binding explicit.</div>
<div><br></div><div>But I guess (your original message wasn't clear on the subject) that what you do when you want to reuse one of these closures is that you copy the closure and its enclosing MethodContext (remember this is a chain and blocks could be nested) and assign the new receiver in the copy. That's not too bad but its still very heavyweight because you're not sharing code between instances.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div class="im">
<div> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">doesNotUnderstand: aMessage</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div><div>
<div><span style="white-space:pre"> </span>"Generic catch all that performs all selectors"</div><div><span style="white-space:pre"> </span>(self can: aMessage selector) ifTrue:</div></div><div><span style="white-space:pre"> [<span style="white-space:normal">^( self s: aMessage selector ) valueWithEffectiveReceiver: self andEnoughArguments: aMessage arguments ].</span></span></div>
<div><span style="white-space:pre"> </span>^ self s: aMessage selector.</div><div></div></div></span></div></div></blockquote><div><br></div></div><div>I take it you'd have to define #valueWithEffectiveReceiver:andEnoughArguments: as BlockClosure has no such beast. If the closure was promoted to a CompiledMethod, then I guess you could use #valueWithReceiver:arguments: and another patched Array. Or did I miss something?</div>
</div></blockquote><div><br></div><div>No, that's it. You could also write it as</div><div> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">^self evaluate: ( self s: aMessage selector ) withEffectiveReceiver: self andEnoughArguments: aMessage arguments</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">and have the extension in your framework not on BlockClosure.</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">And of course your suggestion with CompiledMethod would work.</span></font></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div class="im">
<div> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">As regards more generic property handling I don't know of a better way than the doesNotUnderstand: handler for handling properties held in per-instance dictionaries if the constraint is that you definitely don't want to compile accessors for the property and you are using the vanilla VM.</span></div>
<div><br></div></div><div>I figured the dNU approach was close enough to what Morphic did, that it was "good enough". But I was surprised how </div><div>weird the code got.</div><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
<div><div>But methods are cheap and so I don't see the benefit of avoiding methods in favour of blocks. </div></div></div></span></div></div></blockquote><div><br></div></div><div>It largely has to do with not being able to get methods to actually work :) I originally was trying to patch in CompiledMethods but ran into too many of the blowing up in bizarre ways, and the semantics drifting too far</div>
<div>from the JS version of the API. </div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
<div><div> Vassili came up with the great idea of generating bytecode for slot accessors directly and minting a set of 256 accessors that traversed the parent chain in a loop. Effectively each accessor method looked like</div>
<div><br></div><div>accessSlot0</div><div> | object |</div><div> object := self.</div><div> [object slot0 ifNotNil: [:value| ^value].</div><div> (object := object parentSlot) ~~ nil] whileTrue.</div><div> ^#undefined</div>
</div></div></span></div></div></blockquote><div><br></div></div><div>I have a OO Forth that does the exact same thing, except it rolls native x86 machine code :)</div></div></blockquote><div><br></div><div>Cool :) But note that the JIT does produce x86 code for you so at the metal there's not a lot of difference :)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div class="im"><div> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Both Claus Gittinger and Dan Ingalls have had the idea of creating an object that is an instance of itself. One way, without VM mods (and ignoring issues with compact classes), is to do something like</span></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><div>
<div><div><br></div>
<div>prototype: aPrototype numNewSlots: numNewSlots</div><div> | format object |</div><div> object := (Array new: aPrototype numberOfSlots + numNewSlots + 3).</div><div> object</div><div> at: 1 "superclass" put: aPrototype;</div>
<div> at: 2 "methods" put: MethodDictionary new;</div><div> at: 3 "format" put: (self formatOf: aPrototype format withAdditionalSlots: numNewSlots).</div><div> object changeClassTo: object.</div>
<div> ^object</div><div></div></div></div></span></div></div></blockquote><div><br></div></div><div>I did something similar with another project, but I've found doing the deep copies on the MethodDictionary ends up </div>
<div>failing in weird ways. </div></div></blockquote><div><br></div><div>But you don't need to copy the MethodDictionaries. With the above approach they're shared/inherited. So when a message is sent to a subinstance the lookup machinery will follow the prototype chain until it finds a method or triggers dNU. In the activation self is bound to the original receiver. The issue is hence making sure that slot layouts in subinstances match their parents so that parent methods work correctly on subinstances. But that's not a new problem, Smalltalk does exactly that :)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div class="im"><div> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Combine one with the other and you have the potential for a lean and mean prototype-based system using the existing VM technology, which would mean an efficient JavaScript implementation within Smalltalk.</span></div>
<div><br></div></div><div>I guess I know what the next set of experiments I'm going to do are :)</div><div><br></div><div>Thanks Eliot for thinking through this with me.</div><div><br></div>
<div>The main reason I'm building this, is I've got this very fluid ad hoc Javascript editing environment I wrote that I'm trying to port to Squeak. I've been writing a book on programming that runs the reader through the process of designing a simple 8bit CPU, that has been implemented as step by step drag and drop examples on top of it. </div>
<div><br></div><div>The only problem is that the only JS + HTML5 implementation out there in the wild that can actually handle it is Safari, and I can't bundle that with the book :)</div><div><br></div><div>If I can get it ported to Squeak, I can add an additional appendix and give the code listings in both Smalltalk and Javascript. But I want the code to have direct analogues, so the translations of concepts between languages are</div>
<div>clear.</div></div></blockquote><div><br></div><div>Please keep me in the loop. This is interesting and I'm happy to review.</div><div><br></div><div>cheers</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div></div><div><br></div><div>Dave</div></div>-- <br><font color="#888888">-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/" target="_blank">http://blog.dloh.org/</a><br>
</font><br><br>
<br></blockquote></div><br>