This meeting was skipped as no one was available, but the plan for this meeting is laid out below, and its effectiveness is retrospectively acknowledged in the next TS weekly meeting.
A card needs a name so that they can be
- referred to by JavaScript on the website (not in TokenScript - although might from ther too one day)
- for inheritance (for example, overriding the default ERC20 TokenScript's send action with an action named "send")
There are 3 strategies.
1. Require a card to always have a name.
The argument against it is mostly that the token card often doesn't need a name.
Granted, you need to name token cards if there are more than 1 token cards for the same token.
One such example in production is the Line of Credit token from AAVE, which have 2 token cards one for the owner and the other for the ethereum address holder deligated to withdraw from that line of credit.
Another is the Carma Car Token in-experiment, where you can have access to a car token and all its functions if you are lent the car, not owning it.
But one can argue that these cases are not the norm today (Mid-2020).
2. Give a card a default name
Since it's possible to allow the only token-card to be nameless, one "solution" is to grant a default card name.
This would work for tokens with only one token-card and that is the case for most tokens in existence today (Mid-2020). This is achieved by defining name a required attribute with a default value (under <card>)
<attribute name="name" type="NCName" default="default"/>
But it presents a developer experience problem. A developer would:
- When creating a card, not specify a name, since the IDE would not require one, given default is present in the schema.
- And he goes on to create a 2nd and 3rd card, without names, and get the following error message:
Element 'card': Duplicate key-sequence ['default'] in key identity-constraint 'cardgame'
The offence of the key-uniqueness rule on card names is obscure here because the developer never gave names to the cards in his development journey. The developer might at this point start to Google for the underlying cause and forced to learn what this means, wasting attention that could be used on getting the token stuff right.
3. Apply constraint
For example, require the name either to present, or the card type be 'token' (that it is a token card - as we discussed before, most token cards are the only token card in the respective token)
<assert test="@type = 'token' or exists(@name)" />
This can be fine-tuned to require name except the token-card is the only token-card in the TokenScript. But it presents the same developer experience problem.
This post advocate for 1, that is required every card to have a name. The situation that most TokenScript has only one token-card in it, and therefore doesn't seem to need a name, is addressed by having a name main given in all examples.