<div dir="ltr"><div dir="ltr">Am So., 9. Okt. 2022 um 13:56 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"><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><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"... A common pattern that I observe is that people mold all kinds of things into Smalltalk code just because the tools for browsing it are already there. Rather than build proper tools for the things that are actually not Smalltalk code...</div><div><br></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><div><div></div><div>These methods need be eventually send to the eventualeé. Andsoi think the method implementations in the ERef’s subclassed ETrait (see below, ERef subclassing for each ETrait) provides the entire non-private (private category, methods starting with prv, priv, prim would be excluded from the ETrait’s methods. </div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>If you then change the method on the trait, it will automatically update those method copies in the using classes. </div></div></div></blockquote><div><br></div>Interesting this! So an ETrait generated from a Class ought have the same update with the ETrait’s customized method implementations…</div><div><br></div><div>add/remove a method on the ETrait’s defining class (class asETrait) ought to update the ETrait with the eventualized method implementation, which will update the ERef’s class through normal Trait mechanism. Ask a class #eRefClass to get the ERef subclass for that class’ ETrait. Keep </div></div></div></div></blockquote><div><br></div><div>Let's assume the actual spherical cow runs in the remote system. Locally you have an ERef to the spherical cow, and let's assume that this ERef is actually a member of a subclass of ERef that uses some trait that describes the spherical cow. When the spherical cow is updated in the remote system, you would have to take care of sending that update to the local system yourself. Your implementation could then locally update the trait describing the spherical cow, to update the methods in that ERef subclass. Again I wonder why there needs to be a trait here. You could also update that subclass directly.</div><div><br></div><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, you would still need to implement it yourself that the generated trait or subclass gets updated if you update the real spherical cow class.</div><div> </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><div><div><br></div><div>These ETraits would need to be instance specific, not class-based, UNLESS a new ERef subclass is auto-generated as needed for different eventualeé’s ETrait generating Class. </div></div></div></div></blockquote><div><br></div><div>As I said, traits are attached to classes, so you would definitely need all these auto-generated subclasses. And then, once more, why generate both a trait and a subclass, when just the subclass would be enough.</div><div> </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><div><div><br></div><div>With different ERef subclasses for each target class, with that particular ETrait, browsing the ERef subclass in any browser should be fine displaying the ETrait methods.. </div><div><br></div></div></div></div></blockquote><div><br></div><div>Yes.</div><div> </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><div><div></div><div><br></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"? This is how it works. If you don't want that, you will need to find a workaround or use different means. I do not understand what you mean by "read-only method implementation", but there is no possibility that I know of to avoid that trait methods "back out" if the class already has a method that the trait also provides.</div><div> </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><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>If you want a dynamic, instance-specific display in the protocol browser (or rather InstanceBrowser), at the first glance it does not sound to me like traits would be a fit. </div></div></div></blockquote><div><br></div><div>Instance browser? Huh! Unknown to me…</div></div></div></blockquote><div><br></div><div>When you use "browse protocol" on classes (e. g. from the system browser), you will get a Lexicon (which is-a ProtocolBrowser). When you use "browse protocol" on objects (e. g. from an Inspector), you will get an InstanceBrowser, which looks exactly like a Lexicon except that the frame color is slightly different (if you have colorful windows enabled). The main useful difference is that if you evaluate code in the text pane of an InstanceBrowser, it will evaluate in the context of that inspected object, as if you would evaluate the code in the inspector for that object.</div><div><br></div><div>If you wanted to tweak a tool to display some instance-specific behavior (without generating subclasses), you would adapt/extend/subclass the InstanceBrowser I think.</div><div> </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><div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>If you can derive the methods just from the reference to the remote class, you should better override those messages that the browser sends to determine which methods there are in your eref class. Or implement a custom browser that sends different messages to collect that information.<br></div></div></div></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">The generation of an ETrait from a eventualeé’s Class will compile methods for explicit eventual sending (no #doesNotUnderstand, though that will remain) with non-private selectors as</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">derivedMessageSelector: arg1</div><div style="color:rgb(0,0,0)">    ^ self redirectMessage: (EMessageSend </div><div style="color:rgb(0,0,0)">        selector: derivedMessageSelector</div><div style="color:rgb(0,0,0)">        arg: arg1)</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">Which when called will return an EPromise.</div></div><div><br></div>In this way ERef subclasses per ETrait can provide the interface with forwarding implementations of the Class’ protocol.</div><div><br></div></div></div></div></blockquote><div><br></div><div>The net effect is that when the ERef receives this message, it will go through this generated method rather than through doesNotUnderstand:, plus you have put up this stub method so that the unchanged Smalltalk tools have something to display. If you think that is worth it, alright. But again, you would get the same effect with just generated subclasses, without using any traits.</div><div><br></div><div>Kind regards,</div><div>Jakob</div><div><br></div></div></div>