# To self or not to self? **URL:** \ **Category:** Architecture\ **Created:** [October 18, 2022, 1:38pm UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166 "2022-10-18T13:38:27Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![elplatt](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/elplatt/32/96_2.png) [@elplatt](https://community.spritely.institute/u/elplatt)\ **Post date:** [October 18, 2022, 1:38pm UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/1 "2022-10-18T13:38:27Z")
With most of my recent programming work being in python, one of the adjustments I’ve had to make when experimenting with goblins is not having access to a “self” or “this” reference from within an object. I can see reasons for and against having these references and I was wondering if this was an intentional choice and whether there are any ocap-specific considerations. The main difference this has led to is needing to rely more on composition than I’m used to, in order to have references to objects providing specific functionality or capabilities. ---
**Author:** ![tsyesika](https://avatars.discourse-cdn.com/v4/letter/t/9fc29f/32.png) [@tsyesika](https://community.spritely.institute/u/tsyesika)\ **Post date:** [October 18, 2022, 6:43pm UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/2 "2022-10-18T18:43:19Z")
Not really addressing your question, but something me and @cwebber have done when we’ve needed “self” has been to do something like this: ```nohighlight (use-modules (goblins) (goblins vat)) (define (spawn-hello) (define (^self bcom) (lambda () (format #f "Hello myself! ~a" self))) (define self (spawn ^self)) self) (define a-vat (spawn-vat)) (a-vat (lambda () (define hello-actor (spawn-hello)) (pk 'result ($ hello-actor)))) ``` An example of this in some real code is in the racket edgename database code: [brux/edgenames.rkt · main · spritely / brux · GitLab](https://gitlab.com/spritely/brux/-/blob/main/brux/edgenames.rkt) ---
**Author:** ![jfred](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/jfred/32/18_2.png) [@jfred](https://community.spritely.institute/u/jfred)\ **Post date:** [October 18, 2022, 11:09pm UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/3 "2022-10-18T23:09:11Z")
Also worth noting that in the Racket version’s actor-lib there’s selfish-spawn, which is basically that but abstracted a level: [goblins/actor-lib/selfish-spawn.rkt · master · spritely / goblins · GitLab](https://gitlab.com/spritely/goblins/-/blob/master/goblins/actor-lib/selfish-spawn.rkt) ---
**Author:** ![kris](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/kris/32/114_2.png) [@kris](https://community.spritely.institute/u/kris)\ **Post date:** [October 19, 2022, 1:38am UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/4 "2022-10-19T01:38:34Z")
In Agoric’s Hardened JavaScript, we generally eschew the receiver object (`this`) and we do not allow it at all in the Jessie subset. It’s certainly possible to treat the receiver as just another capability-bearing argument of a pure function, but within that approach, one has to take care to abstain from placing private methods or data on the object. It is far easier to reason about encapsulation as a security primitive in terms of state captured in the closure of a bag of related functions/methods that simply ignore their receiver argument, in order to avoid confusing the rights the object represents from the internal machinery. And, there are of course certainly mechanisms that achieve the same effect and also thread a receiver object. ---
**Author:** ![dale.schumacher](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/dale.schumacher/32/86_2.png) [@dale.schumacher](https://community.spritely.institute/u/dale.schumacher)\ **Post date:** [October 20, 2022, 2:30pm UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/5 "2022-10-20T14:30:16Z")
@cwebber and I have had lively discussions on this topic, and I think we’ve agreed to disagree, or at least have chosen to pursue opposite defaults. The Goblins code you showed depends on a mutable environment in which you can bind `self` after you’ve created the actor that refers to itself. In a pure-functional system (like Humus, for example) that kind of circular reference would require the equivalent of a Y-combinator. I considered that too awkward/ugly, so I prefer to provide a `self` reference (sometimes as a keyword) within every Actor. One pattern that uses `self` is lazy-initialization, where the Actor uses `become` to initialize itself on receipt of its first message-event and resends that message (asynchronously) to itself for handling after initialization. I don’t have the “risk” associated with “private” methods, partly because I don’t have synchronous method-calls, but mostly because `self` is not a privileged reference. It is, in fact, the same reference any other collaborator would use to send an asynchronous message to this actor. I think the distinction comes down to this. Who has a reference to a newly-created actor, the creator only, or the creator and the actor itself? Goblins implements the former, and I prefer the latter. ---
**Author:** ![frandallfarmer](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/frandallfarmer/32/3_2.png) [@frandallfarmer](https://community.spritely.institute/u/frandallfarmer)\ **Post date:** [October 20, 2022, 5:43pm UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/6 "2022-10-20T17:43:33Z")
> [@dale.schumacher](#): > > One pattern that uses `self` is lazy-initialization, where the Actor uses `become` to initialize itself on receipt of its first message-event and resends that message (asynchronously) to itself for handling after initialization. Hmm. This is interesting. I’ve been working with the Unum/Presence model since the beginning, and lazy initialization has always presented a challenge (especially when some Una want to initialize relative to others…). Thanks! ---
**Author:** ![dckc](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/dckc/32/15_2.png) [@dckc](https://community.spritely.institute/u/dckc)\ **Post date:** [October 25, 2022, 1:00am UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/7 "2022-10-25T01:00:49Z")
> In Agoric’s Hardened JavaScript, we generally eschew the receiver object (`this` ) and we do not allow it at all in the Jessie subset. aaand then we hit the upgrade problem. And now we use `this` a little bit. For a sort of OCap ORM. I’m not sure where any good docs are, but I know at least one example… > ---
**Author:** ![vivi](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.spritely.institute/vivi/32/169_2.png) [@vivi](https://community.spritely.institute/u/vivi)\ **Post date:** [February 12, 2023, 2:14am UTC](https://community.spritely.institute/t/to-self-or-not-to-self/166/8 "2023-02-12T02:14:41Z")
I also am running into this specific issue with the little project I am currently working on (tic-tac-toe). I certainly would not _need_ `self`, but it feels lacking just due to the languages I’ve used in the past, for example when using `(methods ...)` if you want to invoke your own method. I have gotten around this constraint by having defines that the methods are bound to (the defined method is `_name` and the method is `[(name) (_name)]`–but it doesn’t feel elegant. In fact, I even attempted to port selfish-spawn to Guile, which I created an MR for: [Port selfish-spawn from Racket actor-lib (!97) · Merge requests · spritely / Goblins - Guile implementation · GitLab](https://gitlab.com/spritely/guile-goblins/-/merge_requests/97) What I really wonder about, is whether it’s possible to use `bcom` if you have a selfish-spawned object. Can a non-selfish object bcom one, and can you bcom anything (selfish or not) effectively if you are a selfish object? If you pass the same `self` - does it have the proper debug name and everything. Worth experimenting with but also perhaps I just need to reframe how I design objects! I am new to all of this, of course.