IRC channel logs
2023-07-03.log
back to list of logs
<vvvvmvr[m]>A conceptual/code organization question about bcom. Say I have an actor A that another (remote) actor B holds a reference to. It seems elegant during a state change for Actor A to become C, to avoid the coordination required to give A another freshly spawned actor reference. However, say we want a local actor D to have access to extra capabilities relating to C that B does not have. How would we encapsulate this behavior/wrap C inside D <vvvvmvr[m]>somehow? Would we want to give A to D when spawning it, and then tell D not to do anything until A becomes C? <vvvvmvr[m]>To be more concrete: I currently have a "lobby" and a "client" object that communicate with each other, until finally both transition into the same "game controller" object. It's a turn based game, and I want to have access to stuff the other player should not, like a "make-move" method, etc. <vvvvmvr[m]>The controller could perhaps have a peer-turn method, to receive moves the peer has made. But I can't give it a my-turn method, because then the peer would have the capability of moving for me. <vvvvmvr[m]>Correction, should be: "...to avoid the coordination required to give B another freshly spawned actor reference..." <flatwhatson>vvvvmvr[m]: have you seen the "ward" pattern? it allows something like private methods, which are only callable by actors which have the associated sealer <vvvvmvr[m]>So, would I have to give A a warden, to pass along to C, then ? <vvvvmvr[m]>Another bcom question - it seems that if I call bcom inside a callback, then references to the old object remain? What's going on there? My understanding is that, after bcom gets called and the object is transformed, the references should update, right? <flatwhatson>my understanding is that it's not an "old object" becoming a "new object"; it's a state transition for one object <vvvvmvr[m]>what I'm seeing when bcom isn't the last statement in a method, is that the actor type you choose is initalized, but the previous actor type remains in the reference <vvvvmvr[m]>I have this "lobby" which calls bcom inside a callback, and a client which calls bcom and then returns a different object. And the definitions for them I have in the repl still point to the lobby/picker, rather than the object type they are supposed to become. <vvvvmvr[m]>> [bcom] must be called in a tail position, since bcom returns a datastructure demonstrating that this object is choosing to change its value (part of Goblins’ quasi-functional design). <vvvvmvr[m]>> bcom can also take a second argument which will be returned from the object’s invocation as a return value. This allows an object to both change its behavior and return a value with the same invocation. <vvvvmvr[m]> * > bcom can also take a second argument which will be returned from the object’s invocation as a return value. This allows an object to both change its behavior and return a value with the same invocation. <vvvvmvr[m]>One thing that might be nice is to have error handling that detects bcom not being used in a tail position and creates an error :) <vvvvmvr[m]>I would still like to figure out if it's possible to somehow initiate a bcom from a promise callback. Because I have the lobby wait on the client to do something, and need to rely on the value it picks before i call bcom.