I see. Thanks for this. A few follow ups below…I hope you don’t mind exploring this with me, further. Tell me more!

> On Oct 9, 2022, at 06:01, Jakob Reschke <jakres+squeak at gmail.com> wrote:
> 
> 
> Hi rabbit,
> 
> Traits are used by classes, not by instances, but traits can supply methods both to the instance side and the class side.

Yes I understand this…still…I would generate an ETrait from the eventualeé’s Class. For now we’ll assume a spherical cow and so the eventualeé’s class is local. This is our useCase, an ETrait…

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.

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

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!

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. 

> If you then change the method on the trait, it will automatically update those method copies in the using classes.

Interesting this! So an ETrait generated from a Class ought have the same update with the ETrait’s customized method implementations…

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 

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. 

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

Example: NamingBroker vis-a-vis DistributionBroker. There would be 2 ERef subclasses one per, named #NamingBrokerERef and DistributionBrokerERef, and BridgingBrokerERef and ChannelSessionERef…

> When you send a message that the trait method can handle to an object of the class that uses the trait, it will run its copy of the trait method—just like the method dictionary/lookup usually works.

Right!

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

Not necessary, I think. Possible to specify read-only method implementations?

> Now whether traits could help you depends on how you implemented erefs and do the Smalltalk message processing.

Well in ERefs design there are message calling & message sending. 

Calling is normal sequential immediate message passing, with immediate returns: standard Squeak calls. 

Sending is eventual. The messageSend is scheduled in the VatZ’ queues and an eventual Promise is returned immediately for the delayed resolution once the eventual computation is completed. Further sends to the EPromise will queue in the promise for forwarding upon its resolution. Currently, an ERef’s #doesNotUnderstand: override converts all into message sends. When a real message send is pulled off the VatZ’ scheduled queue and the eventualeé really does not understandthe sent selector, the EPromise’ resolver for the send is crashed with an exception. #whenRejected: handlers are activated with a EBrokenError.

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

Instance browser? Huh! Unknown to me…

I’m not sure this is the case. They may still prove useful. 

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

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

derivedMessageSelector: arg1
    ^ self redirectMessage: (EMessageSend 
        selector: derivedMessageSelector
        arg: arg1)

Which when called will return an EPromise.

In this way ERef subclasses per ETrait can provide the interface with forwarding implementations of the Class’ protocol.

> Since Java 8, interfaces can provide "default" implementations of methods, which allows you to use them for the same purpose as you can use traits in Smalltalk. Up to Java 7, interfaces could only declare methods, but not provide an implementation. And since we do not use static typing in Smalltalk, that original functionality of interfaces is unnecessary in Smalltalk: we do not have to declare in advance which messages the class understands. So since traits exist to provide implementations, not specify interfaces, they are rather the complementary functionality to what Java interfaces originally were.

Alright, thanks!

> 
> Kind regards,
> Jakob

Have a good one; keep it, light.
Kindly,
rabbit
. .. … ‘…^,^


Sent from Callisto House Mobile :: decentralized mobile homeless solutions

Der Anführer kontrolliert alles,
🐇🐇🐇🐇🐇🐇

>> Am So., 9. Okt. 2022 um 08:34 Uhr schrieb rabbit <rabbit at callistohouse.org>:
>> Currently inspecting and selecting an eventual ref blows up the image. The cause is unknown. Selecting ‘all inst variables’ does not. I’ll need to look 👀 into this. 
>> 
>> An eref references a remote class, so if an eref needs to display in the browser the protocol for that class. Can a class trait be attached to an instance to allow this? Will the trait means calls to a method on that classTrait runs that method? Is there a way to have a classTrait to provide the message interface without the methods being implemented on that eref, such that those classTrait protocol methods get forwarded to the eventualeé?
>> 
>> I know so little about Traits! Are they similar to Java’s interfaces?
>> 
>> Have a good one; keep it, light.
>> Kindly,
>> rabbit
>> . .. … ‘…^,^
>> 
>> 
>> Sent from Callisto House Mobile :: decentralized mobile homeless solutions
>> 
>> Der Anführer kontrolliert alles,
>> 🐇🐇🐇🐇🐇🐇
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221009/663fd630/attachment-0001.html>