These specify what I can do with an object. They are specified on object level but can be used on variable level to constrain objects passed to stuff.
I own the thing. It is my thing. I am free to mutate or modify it, safe in knowing that nobody else can touch this thing.
It is only bound to a single variable.
But as a consequence, in order to give the
thing to someone else, I need to relinquish
possession of that thing. To do that,
I consume the thing. This sounds a bit like
Rust's move semantics.
The compiler will tell me when a thing should be consumed - as the message "not a subcap of iso".
However, this is not the only case in which this message will appear.
I can read the thing but I cannot change it at all - I borrowed it from another actor or object. The good news is that I can also go share it with another object or actor without worrying about consuming it.
val sounds a bit like const (C/C++/ES6) or
final (Java), but also may provide stronger
guarantees.
I own the thing, however other things may also have references to the thing.
>> Is iso a subcap of ref?
This is "normal" pass-by-reference, mutable behaviour we all know from Java, Python, and a bunch of other languages.
If I have some boxed data, I can read it
but I can't change it at all. Oddly, SQL views
come to mind.
This bit from the docs seems important:
[
box] allows you to write code that can work for both val and ref variables, as long as it doesn't write to the object.
OK, so we have a happy little tree of caps now?
box
/ \
ref val
|
iso
This is for the things I want to make available to
others, however I want to write to that thing too.
The way I do that is by giving out boxes of the
stuff!
actor Me | actor Cat
|
* Starts writing a |
trn letter to others |
|
* Hey cat, want to ------> * Receives my
read my letter? | letter in a box
|
* I continue writing | * "no wat r u doing"
my letter | * "meow"
A rather special capability that just lets you compare
stuff by identity. I can't read or write to stuff in variables
with the tag capability - but that's not a bad thing!
No matter what kind of reference you have to an actor,
you can still send messages to it (which I guess is a good
thing as actors by default give you tag references back
from their constructors).
more capability-restricted
more shareable
↑
tag
/
--- box
/ / \
ref | val
/ trn
|
iso
↓
less shareable
less capability-restricted
← →
makes makes
Any Rand Karl Marx
happy happy
Note that this may very well be wrong but that's basically how I understand Pony capabilities after reading the official docs at https://tutorial.ponylang.org/capabilities/reference-capabilities.html