-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ERTP] Design Changes (to be split up into issues per task) #385
Comments
There's an experimental branch that has some of these changes: https://github.com/Agoric/agoric-sdk/tree/branded-operations-strip-for-parts It has other changes that we probably don't want and needs to be stripped for parts. |
A couple of naming convention proposals:
|
Naming changes based on design session Feb 11:
|
I was thinking |
Good point. You're right. That's what we had said |
assay
toissuer
mint
toissuerAdmin
brand
object. The brand is shared by the issuer, issuerAdmin, purses, and payments of a particular kind. See item 4 for why this is helpful for removing an anti-pattern of use. The brand should have a method that takes an issuer as a parameter and returns a boolean, stating whether the issuer belongs to that brand. This is to avoid issuers picking up another issuers brand and passing themselves off as that brand.issuer
. The only methods that should remain aregetMemo
(to get a string message for that particular payment or purse), andgetAllegedBrand
, which returns an object which is thebrand
. In particular, we want to remove thegetAssay/getIssuer
pattern that we have seen, where a person receives a payment that should not be relied on, and then they get their assay/issuer (which they normally should be able to rely on) from the untrusted payment. Being able to get an object that you should be able to rely on from an object that you should not be able to rely on is an anti-pattern.units
toamount
unitOps
toamountOperations
amountOperations
, we want to simplify as much as possible so that it is very clear that anamount
is merely a branded extent/quantity etc. This means getting rid of the description for now. We should also clarify the use of a WeakSet as a cache so that it is known to be nothing special, just a performance enhancement.extent
to ?? (unbrandedAmount, quantity)?with
toadd
without
tosubtractNonNeg
or something similar. (Note: we cannot usesubtract
on its own because our version is not set subtraction. If the left does not contain the right, we must throw an error. For natural numbers as in the case of fungible tokens, we throw if the subtraction results in a negative number.)includes
toisGTE
The text was updated successfully, but these errors were encountered: