[book] Witness #67
[book] Witness #67
Conversation
| Witness is a pattern of proving an existence by constructing a proof. In the context of programming, | ||
| witness is a way to prove a certain property of a system by providing a value that can only be | ||
| constructed if the property holds. |
There was a problem hiding this comment.
I wonder if you need the first sentence -- I think it might be fine to drop it. It overlaps with the next sentence, and I'm having a hard time getting it to work just right because "an existence" makes me wonder "of what", and it's kind of the other way around, "the existence of the witness is the proof of some property, by construction", but this is essentially what you are saying in the next line.
| Witness is a pattern of proving an existence by constructing a proof. In the context of programming, | |
| witness is a way to prove a certain property of a system by providing a value that can only be | |
| constructed if the property holds. | |
| In the context of programming, a witness is a way to prove a certain property of a system by providing a | |
| value that can only be constructed if the property holds. |
| ``` | ||
| Practically speaking, for the witness to be used, there has to be a function that expects a witness | ||
| as an argument. In the example below it is the `new` function that expects a witness of the `T` type | ||
| to create a `Instance<T>` instance. |
There was a problem hiding this comment.
nit
| to create a `Instance<T>` instance. | |
| to create an `Instance<T>` instance. |
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## "Abstract Class" | ||
| The instance of the struct `W` is passed into the `new` function to create an `Instance<W>`, thereby |
There was a problem hiding this comment.
Is it worth reinforcing here that if you are given an Instance<W> you know that it came from the module that defined W as long as there isn't a public function in that module that constructs values of type W?
| The following example demonstrates a custom `RegulatedCoin` type with implementable functions. The | ||
| actual implementation of the `mint`, `burn`, and `transfer` functions is left to the application | ||
| module, while the `join` function is publicly available. | ||
| Witness allows generic types to be instantiated with a concrete type. This is useful for inheriting |
There was a problem hiding this comment.
This section seems to be trying really hard to avoid terms like "abstract class" or "inheritance" -- is that intentional? Here's the best I could come up with without that restriction:
Witnesses can be used to create a pattern resembling abstract classes, where one module implements base functionality for another module to delegate to or override.
| available and does not require a Witness. | ||
| In the example above, which is borrowed from the `balance` module of the | ||
| [Sui Framework](./sui-framework.md), the `Supply` a generic struct that can be constructed only by | ||
| supplying a witness of the type `T`. The witness is taken by value and _discarded_ - hence the `T` |
There was a problem hiding this comment.
| supplying a witness of the type `T`. The witness is taken by value and _discarded_ - hence the `T` | |
| supplying a witness of the type `T`. The witness is taken by value and _discarded_ - hence `T` |
| > consume a Ticket) for the sake of clarity and simplicity. The full example is available in the | ||
| > [Move Book](https://github.com/MystenLabs/move-book/tree/main/packages/samples/examples) | ||
| > repository. | ||
| The instantiated `Supply<T>` can then be used to mint new `Balance<T>`'s, where `T` is the type of |
There was a problem hiding this comment.
Potential reinforcing point here: It allows the module that defines T (the coin marker type) to control when and how supply is created and destroyed.
No description provided.