4 ms·

That looks like a convoluted way to describe dependency injection to me, what am I missing.

noelwelsh 4mo ago
You're right, they are related. One difference is simply lineage. Capabilities come out of the erights / security world (e.g. [0]), while dependency injection comes from the XP / agile / Martin Fowler world. More interesting is that to do capabilities correctly you need some type system extensions, namely capture checking. Essentially, this means you delimit where a program can hold a reference to a value derived from a capability. So if you have a function that allocates memory, you can say "there are no references to any allocated memory outside this function call" and hence no use-after-free bugs. It gives a form of resource management that is simpler than Rust's lifetimes. See [1] and [2]. (Technically it's a modal type system versus Rust's substructural type system.) To my mind it's an obvious thing for Zig to add. Shameless plug. If you're interested in more on this, for a programmer's rather than academic perspective, this is going into my book [3]. I'm writing the chapter of capability passing right now. Back to writing! [0]: https://blog.acolyer.org/2016/02/16/capability-myths-demolished/ https://blog.acolyer.org/2016/02/16/capability-myths-demolis... [1]: https://effekt-lang.org/tour/captures https://effekt-lang.org/tour/captures [2]: https://docs.scala-lang.org/scala3/reference/experimental/cc.html https://docs.scala-lang.org/scala3/reference/experimental/cc... [3]: https://functionalprogrammingstrategies.com/ https://functionalprogrammingstrategies.com/
- epolanski 4mo ago
  So it's essentially low level dependency injection where it's not just about the interface but the system and it's resources too, right? I will take a look at your content, these topics interest me a lot.
  - noelwelsh 4mo ago
    That's a reasonable way of looking at it, but capabilities are not restricted to low-level system properties. Here's a terminal UI system built around three main capabilities: - layout (adding components to the component tree) - event (handling user input events) - react (reacting to changes in reactive values) https://github.com/creativescala/terminus/tree/main/ui/shared/src/main/scala/terminus/ui https://github.com/creativescala/terminus/tree/main/ui/share... This is the case study I'm using for the book chapter.
Veserv 4mo ago
Capability passing and dependency injection are just convoluted ways to describe passing parameters instead of using globals. Capability passing is just extending that to the level of imports. Your files do not import the global I/O library and then use io.print(). They are passed a I/O library as the parameter {io} which defines a print() function and then call io.print().

You're right, they are related. One difference is simply lineage. Capabilities come out of the erights / security world (e.g. [0]), while dependency injection comes from the XP / agile / Martin Fowler world. More interesting is that to do capabilities correctly you need some type system extensions, namely capture checking. Essentially, this means you delimit where a program can hold a reference to a value derived from a capability. So if you have a function that allocates memory, you can say "there are no references to any allocated memory outside this function call" and hence no use-after-free bugs. It gives a form of resource management that is simpler than Rust's lifetimes. See [1] and [2]. (Technically it's a modal type system versus Rust's substructural type system.) To my mind it's an obvious thing for Zig to add. Shameless plug. If you're interested in more on this, for a programmer's rather than academic perspective, this is going into my book [3]. I'm writing the chapter of capability passing right now. Back to writing! [0]: https://blog.acolyer.org/2016/02/16/capability-myths-demolished/ https://blog.acolyer.org/2016/02/16/capability-myths-demolis... [1]: https://effekt-lang.org/tour/captures https://effekt-lang.org/tour/captures [2]: https://docs.scala-lang.org/scala3/reference/experimental/cc.html https://docs.scala-lang.org/scala3/reference/experimental/cc... [3]: https://functionalprogrammingstrategies.com/ https://functionalprogrammingstrategies.com/

epolanski 4mo ago
So it's essentially low level dependency injection where it's not just about the interface but the system and it's resources too, right? I will take a look at your content, these topics interest me a lot.
- noelwelsh 4mo ago
  That's a reasonable way of looking at it, but capabilities are not restricted to low-level system properties. Here's a terminal UI system built around three main capabilities: - layout (adding components to the component tree) - event (handling user input events) - react (reacting to changes in reactive values) https://github.com/creativescala/terminus/tree/main/ui/shared/src/main/scala/terminus/ui https://github.com/creativescala/terminus/tree/main/ui/share... This is the case study I'm using for the book chapter.

Veserv 4mo ago

Capability passing and dependency injection are just convoluted ways to describe passing parameters instead of using globals. Capability passing is just extending that to the level of imports. Your files do not import the global I/O library and then use io.print(). They are passed a I/O library as the parameter {io} which defines a print() function and then call io.print().