It is currently possible to send portal references from one portal (a) task to another (b), and this would (currently) enable the other portal task (b) to send messages to the received portal reference. Instead, the programming model as we have described it should not allow this: the portal references to which a portal task may send messages to are to be defined statically in the program definition.
To clarify, the problem is the following. Consider two portal tasks, (a) and (b). Portal task a can send a portal reference to task (b). Then, (b) can (currently) use this reference to send a message to it. However, this may cause an error, as at runtime there may not be a connection from (b) to the reference which it holds. This is due to the runtime only ensuring to establish the static connections as known at compile time. Instead we should limit this.
As I see it, there are two main options we can go by:
1) We can either implement it in the way of LaCasa [1], which uses some neat tricks. The benefit of this approach is that it is rather light-weight, and we have some experience with it. It should be no problem to implement it.
2) We can also explore using capture checking for this [2]. The benefit of this approach is that it uses the intended language features to achieve this. The potential down side is that it is still an early experimental feature, and may change significantly over time.
[1] Philipp Haller and Alex Loiko. 2016. LaCasa: lightweight affinity and object capabilities in Scala. In Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2016). Association for Computing Machinery, New York, NY, USA, 272–291. https://doi.org/10.1145/2983990.2984042
[2] Capture Checking https://docs.scala-lang.org/scala3/reference/experimental/cc.html
It is currently possible to send portal references from one portal (a) task to another (b), and this would (currently) enable the other portal task (b) to send messages to the received portal reference. Instead, the programming model as we have described it should not allow this: the portal references to which a portal task may send messages to are to be defined statically in the program definition.
To clarify, the problem is the following. Consider two portal tasks, (a) and (b). Portal task a can send a portal reference to task (b). Then, (b) can (currently) use this reference to send a message to it. However, this may cause an error, as at runtime there may not be a connection from (b) to the reference which it holds. This is due to the runtime only ensuring to establish the static connections as known at compile time. Instead we should limit this.
As I see it, there are two main options we can go by: 1) We can either implement it in the way of LaCasa [1], which uses some neat tricks. The benefit of this approach is that it is rather light-weight, and we have some experience with it. It should be no problem to implement it. 2) We can also explore using capture checking for this [2]. The benefit of this approach is that it uses the intended language features to achieve this. The potential down side is that it is still an early experimental feature, and may change significantly over time.
[1] Philipp Haller and Alex Loiko. 2016. LaCasa: lightweight affinity and object capabilities in Scala. In Proceedings of the 2016 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2016). Association for Computing Machinery, New York, NY, USA, 272–291. https://doi.org/10.1145/2983990.2984042 [2] Capture Checking https://docs.scala-lang.org/scala3/reference/experimental/cc.html