<div dir="ltr"><div dir="ltr">Am So., 9. Okt. 2022 um 20:15 Uhr schrieb rabbit <<a href="mailto:rabbit@callistohouse.org">rabbit@callistohouse.org</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Jakob, May I receive your permission to add this email thread to the ESqueak Design?<br><br></div></blockquote><div><br></div><div>Sure why not. If I wanted to keep anything that I share here secret, I would not share it here. ;-) But in my opinion, email threads hardly make good documentation. I always roll my eyes if I find a Squeak Wiki page that is just a collection of copy&pasted emails.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr"><blockquote type="cite">On Oct 9, 2022, at 14:11, rabbit <<a href="mailto:rabbit@callistohouse.org" target="_blank">rabbit@callistohouse.org</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div><div dir="ltr"><blockquote type="cite">On Oct 9, 2022, at 11:42, Jakob Reschke <<a href="mailto:jakres%2Bsqueak@gmail.com" target="_blank">jakres+squeak@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">Am So., 9. Okt. 2022 um 13:56 Uhr schrieb rabbit <<a href="mailto:rabbit@callistohouse.org" target="_blank">rabbit@callistohouse.org</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><blockquote type="cite">On Oct 9, 2022, at 06:01, Jakob Reschke <<a href="mailto:jakres%2Bsqueak@gmail.com" target="_blank">jakres+squeak@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi rabbit,<div><br></div><div>Traits are used by classes, not by instances, but traits can supply methods both to the instance side and the class side. </div></div></div></blockquote><div><br></div>Yes I understand this…still…I would generate an ETrait from the eventualeé’s Class. <span style="color:rgb(0,0,0)">For now we’ll assume a spherical cow and so the eventualeé’s class is local. This is our useCase, an ETrait…</span><div><br></div><div>If that class were unknown to the client, an eventual ‘eref class asETrait’ would return the ETrait for that class over the inet to the client, in an archived box, pass-by-copy, a later detail. Spherical cow.<div><div><br></div></div></div></div></blockquote><div><br></div><div>Is there a particular reason to send/make a trait rather than a class? In particular if you need dynamically generated subclasses of ERef anyway.</div></div></div></div></blockquote><div><br></div><div><span style="color:rgb(0,0,0)">My suspicion was Squeak’s Traits provided methods and perhaps could update. Which it does! Yay!</span></div></div></div></blockquote></div></blockquote><div>But it updates methods / propagates changes only within the same image. For anything beyond, you have to take care of the synchronization. You can use Distributed ELinda or anything else to accomplish that, sure. But traits will not do the work for you.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>If you use a trait in a class, the trait's methods are copied to the MethodDictionary of that class (and the corresponding classTrait methods go to the dictionary of the corresponding Metaclass). </div></div></div></blockquote><div><br></div>Right so what are the method implementations of an ETrait? This is the key to my using them. As this is strictly for documentation and browsing of the class of an instance, for those developers who ask “what are the messages I can send to my ERef?” Open a browser on its class and see!</div></div></div></div></blockquote><div><br></div><div>Not sure whether putting something that the system can potentially execute into the system is the right way to obtain something "strictly for documentation"... </div></div></div></div></blockquote><div><br></div><div>I’m confused. That’s just constructing BlockClosures with anonymous code to run, right? That’s how a Browser works, right?</div><div><br></div></div></div></blockquote></div></blockquote><div>Errm, no. Unless we are talking about different things. If you save a method in the browser, the compiler produces a CompiledMethod, which gets installed in the class's method dictionary. No BlockClosure here.</div><div>But even if it were so, a BlockClosure would be even less suitable as a piece of documentation, wouldn't it?</div><div><br></div><div>Let me rephrase my original, complicated sentence: </div><div>You want to make the protocol of the remote object discoverable. You already have the mechanism to send messages to the remote—that is your doesNotUnderstand: implementation in the ERef, right? Why install further methods in the local system, just to put up something that can be browsed with the existing tools? Instead you could do it like the FileContentsBrowser and use PseudoClass to give the user something browseable, without actually loading methods or creating classes that mirror the remote class in some way. Or generate a HelpTopic and open that in the HelpBrowser...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div><div></div>So as E-SSE is different, an extension to Core Smalltalk, a custom browser needs be provided. The Browser was built to support that and Prolog provides an Excellent example! I’ll get that loading soon. I believe it’s not been published to the SM 6.1 version. I know very little about it. Can you tell me more?</div></div></blockquote></div></blockquote><div>No, I have not looked at the Prolog implementation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Even if this all runs in the same image, and the spherical cow just runs in a different Vat than the one where the ERef to it is, </div></div></div></div></blockquote><div><br></div>Yessir, multiple Vats within the same system goes through sockets so samesame.</div></div></blockquote></div></blockquote><div>Is it not unnecessarily expensive to go through OS system calls for the sockets when you just want to talk to the neighboring objects in the same image...?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>And then, once more, why generate both a trait and a subclass, when just the subclass would be enough.</div></div></div></div></blockquote><div><br></div>Ah, I understand your point now. Why Double generation you’re asking. In my view, I’ve pointed out it’s a functional update mechanism, just double meta generation. One at the remote Class host and one in the local TraitERef case. Also it’s a publishable artifact that’s distributable. </div><div><br></div><div>How else to send method updates? BTW, sending an eTriggerEvent: exactly when the method is compiled into the Class provides immediate update push events. </div></div></blockquote></div></blockquote><div>Well, as I wrote above, traits do not do any of this for you. They are also not more suitable to be transferred over the wire than a regular class, as far as I can tell.</div><div><br></div><div>The purpose of traits is to share common method implementations among classes that are not related via the class-superclass relationship. As is, this only works within the same image. Moreover you do not want to share implementations, only information about the protocol. So I do not see how traits would help you.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><div></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>When you implement your own method in the class, even though that method would also be provided by a trait that the class uses, the trait will skip that method and leave your own method in place.</div></div></div></blockquote><div><br></div><div>Not necessary, I think. Possible to specify read-only method implementations?</div></div></div></div></div></blockquote><div><br></div><div>What do you mean "Not necessary"? </div></div></div></div></blockquote><div><br></div>The Class Host has generated  it’s ETrait with forwarding methods already. Advisable not to change the methods in a ETraitERef class.</div><div><br></div></div></blockquote></div></blockquote><div>Maybe I have some misunderstanding. You are mentioning many different class names and terms from your system about which I have almost zero prior knowledge. Talking about two Squeak instances that are connected through your system, where are these various classes situated, and which ones are proxying for another?</div><div><br></div><div>Example table:</div><div>|| System that uses the spherical cow || System that hosts the spherical cow ||</div><div>| ERef | SphericalCow (= the "eventualeé's class"?) |</div><div>| ETraitERef (is this a subclass of ERef?) | ETrait? |</div><div>| ETraitERef for the protocol description of SphericalCow | Generated ETrait that describes the protocol of SphericalCow? |</div><div>| Generated trait that describes the protocol of SphericalCow? | n/a? |</div><div>| Generated subclass of ERef (?) for the SphericalCow? (is supposed to use which of the two traits above?) | SphericalCow |</div><div><br></div><div>The browsing of the protocol is supposed to happen in the system on the left side of the table. So far I was thinking that what you are talking about is supposed to happen only on the left side of the table. But maybe you had in mind to implement some things on the right side instead.</div><div><br></div><div>Should the tools talk to something on the right side, through your system? If this was your idea, I would assume that the immediate problem is that none of the existing Squeak tools/browsers can deal with EPromises that the ERef proxy being browsed would return for any query message that the browsers send to it.</div><div><br></div><div>So either you need tools that can deal with EPromises, or you do need to transmit some protocol description explicitly and browse that instead. I was assuming the latter, and you also mentioned encoding the trait and passing a copy of it. And if that is so, why not directly pass a copy of a class (that has the EMessageSend in each method rather than the actual implementation), or better a PseudoClass, or just a collection of the selectors that the real class can understand, rather than a trait?</div><div><br class="gmail-Apple-interchange-newline">A trait may be seen as a collection of methods that happens to be browseable with the Smalltalk tools, but, I repeat, its purpose is to share implementations among unrelated classes. Apart from the fact that you do not wish to share implementations, that sharing does not work out of the box across the middle vertical line of the table above. And looking at only the left side in isolation, or only the right side, I do not see yet where this implementation sharing would be beneficial.<br></div><div><br></div><div>What is also unclear to me is when you want to transmit this protocol description. Just in time when the user wants to browse the protocol of the remote object? Or as soon as the left side establishes the reference to the object on the right side? If you wanted the ERef object to be a member of a generated subclass that is tailored to proxy one specific class from the remote system, it would only make sense to me with the second option. But it may be overkill to create a tailored proxy class for every remote class that you encounter.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>there is no possibility that I know of to avoid that trait methods "back out" if the class already up has a method that the trait also provides.</div></div></div></div></blockquote><div><br></div>Yes, this is what I’m trying to block a naive user from being able to do. IDK, </div><div><br></div></div></blockquote></div></blockquote><div>Then I advise against giving them some piece of Smalltalk in the first place. At the heart of Smalltalk is that you can change anything about the system if you want to. Alternatively, just let them try to change it. Nobody prevents naive users from evaluating `true become: false` either...</div><div><br></div></div></div>