# Extensibility

**URL:** <https://forum.flow.com/t/extensibility/622>\
**Category:** 🏄🏻‍♀️ Cadence\
**Created:** [October 19, 2020, 7:54pm UTC](https://forum.flow.com/t/extensibility/622 "2020-10-19T19:54:54Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 19, 2020, 7:54pm UTC](https://forum.flow.com/t/extensibility/622/1 "2020-10-19T19:54:54Z")

</div>

Hello, Cadence Community!

We would like to add support for extending existing types with additional data and functionality, retro-actively, i.e. without modifying the original declaration.

This was requested in the following GitHub issue: [https://github.com/onflow/cadence/issues/357](https://github.com/onflow/cadence/issues/357).

The goal of this topic is to work out a pitch and eventually concrete proposal for how to achieve this in Cadence.This could be for example in the form of a [Flow Improvement Proposal](https://github.com/onflow/flow/blob/master/flips/README.md) ([template](https://github.com/onflow/flow/blob/master/flips/yyyymmdd-flip-template.md)), and/or a [Cadence RFC](https://github.com/onflow/cadence/blob/master/rfcs/0000-template.md).

We can use this topic to collect e.g. prior art, use-cases, answer open questions, and work together on the design proposal.

Once we have a proposal, we can move on to work on the implementation of it (potentially starting with an MVP/subset).

I’ll update the remainder with the latest state of the proposal.

* * *

## Summary

This proposal describes a new language feature: Support for extending existing types with additional data and functionality, retro-actively, i.e. without modifying the original declaration. This feature is purely additive, i.e. no existing functionality is changed or removed.

## Motivation

It is currently not possible to extend existing types unless the original author did explicitly make provisions for future extensions.

For example, to make a resource declaration extensible, its author may add a field that allows any other code to store an extension. However, this requires a lot of boilerplate and is brittle. The original type must be prepared to store additional data with potentially additional functionality.

## Use cases

- [Adding hats, apparel and accessories to CryptoKitties](https://kittyhats.co/)
- Storing e.g. a signature or edition information for a given NFT, e.g. adding autographs to NBA TopShot moments
- Paying the original creator of an NFT a royalty on resale
- Storing ownership trail information (a NFT owned by somebody might be more valuable? Lets say I own a TopShot moment of Zion that he has owned himself?)
- Add utility functionality, e.g. export a HTML representation of an NFT

## Prior art

- [Extension methods in C#](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods)
- [Extension methods in Scala/Dotty](http://dotty.epfl.ch/docs/reference/contextual/extension-methods.html)
- [Extensions in Kotlin](https://kotlinlang.org/docs/reference/extensions.html)
- [Extensions in Swift](https://docs.swift.org/swift-book/LanguageGuide/Extensions.html)
- [EIP-998: ERC-998 Composable Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-998)

## Design

This proposal specifies the ability to extend resources with additional functions. Other extensions are out-of-scope and could be proposed in the future. See the “Future / Out-of-scope” section below.

### Declaration

Extension function declarations are able to refer to `self`, just like original function declarations. This makes them natural to declare and to read.

Extension function declarations have the same access to fields and functions as code _outside_ the original type declaration, i.e. they should be able perform everything that is possible externally, but also not more. This ensures that an extension cannot exploit the extended type by extending original functionality. As a result, an extension function declaration is not able to access private fields or function of the extended type.

Extension function declarations are not able to override existing function declarations. For example, if a resource declares a function named `use`, extensions may not declare a function named `use`, even if it has a different signature (different parameters and/or different return type).

#### Syntax

TBD

### Use

The owner of a resource may freely add and remove extensions.

Extensions have an order, the order in which the extensions where added and removed from the extended object. This allows distinguish usage patterns. For example, an art piece might be first framed, and then signed; or it could be first signed and then framed.

TBD

#### Syntax

TBD

## Drawbacks

Adding a new language feature has the downside of complexity: users have to learn yet another concept, and it also complicates the language implementation.

However, this language feature can be disclosed progressively, users can discover and use it when needed, it is not necessary to be understood for core use-cases of the language, i.e. the target audience is mostly “power-users”.

## Future / Out-of-scope

### Kinds

This proposal only specifies the extension of resources with additional functions.

Other extensions are out-of-scope and could be proposed in the future:

- Extension of other kinds of types, such as structs, contracts, events
- Extension of interfaces
- Providing default implementations of interfaces
- Extension of types to conform to more interfaces

### Unremovable extensions

Some extension should not be removable. A future proposal may restrict certain extensions to be removed from an extended object.

### Composability

Some code authors may declare up-front that the type they declare should always have an extension, i.e. they want to re-use code that has been written as an extension.  
A future proposal may define how this could be achieved.

## Open questions

### Declaration

- Extension functions:

- Should it be possible to declare additional fields? If so

### Usage

- How can extension be used and what is the syntax for it?

- If extensions can declare additional fields, how are they initialized, i.e if the extension would declare an additional initializer for those extension’s fields, how is the initializer called?

- What is the subtyping relation for extension types? When type `T` is extended with `U` and then `V`, is it a subtype of a type `T + V + U`? (note the difference in order)

### Other

- How do extensions interact with interfaces? (See “How are extensions resolved/dispatched?”)

- Can this proposal be added in a backwards-compatible way? Does existing code or stored data need to be migrated?

---

<div class="post-metadata">

**Author:** ![bjartek](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bjartek/32/143_2.png) [@bjartek](https://forum.flow.com/u/bjartek)\
**Post date:** [October 19, 2020, 8:24pm UTC](https://forum.flow.com/t/extensibility/622/2 "2020-10-19T20:24:20Z")

</div>

[https://github.com/bjartek/flow-nft-mixin/tree/trait](https://github.com/bjartek/flow-nft-mixin/tree/trait) is a little something I made.

It does not answer all of the questions above but It solves some of them.

---

<div class="post-metadata">

**Author:** ![woody](https://avatars.discourse-cdn.com/v4/letter/w/ac91a4/32.png) [@woody](https://forum.flow.com/u/woody)\
**Post date:** [October 21, 2020, 7:12pm UTC](https://forum.flow.com/t/extensibility/622/3 "2020-10-21T19:12:21Z")

</div>

I would like to be able to create an interface extension to provide default function implementations, the way one can do with Swift protocol extensions.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 21, 2020, 10:44pm UTC](https://forum.flow.com/t/extensibility/622/4 "2020-10-21T22:44:21Z")

</div>

I’ve updated the proposal and the open questions with the notes from out last call.

I’d be happy to suggest answers to some of the questions, but am also curious to hear what others think, and can also wait until the next call and we can discuss them together.

---

<div class="post-metadata">

**Author:** ![bjartek](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bjartek/32/143_2.png) [@bjartek](https://forum.flow.com/u/bjartek)\
**Post date:** [October 22, 2020, 7:05pm UTC](https://forum.flow.com/t/extensibility/622/5 "2020-10-22T19:05:20Z")

</div>

The extensions above in your examples are AnyStruct, while in my mixin proposal they are AnyResource. What it the practiacal difference here? Can an struct contain another Resource or Capability?

---

<div class="post-metadata">

**Author:** ![bjartek](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bjartek/32/143_2.png) [@bjartek](https://forum.flow.com/u/bjartek)\
**Post date:** [October 22, 2020, 7:32pm UTC](https://forum.flow.com/t/extensibility/622/6 "2020-10-22T19:32:51Z")

</div>

Use cases I can see extensions beeing used for right now:

- paying the original creator of an NFT a royalty on resale.
- storing a signature for a given NFT (could be combined with the above)
- storing ownership trail information (a NFT owned by somebody might be more valuable? Lets say I own a TopShot moment of Zion that he has owned himself?)
- storing edition information for an NFT
- formalize how to fetch onChain stored content. Might be possible to chunk up content into base64 batches and store a capability to the chunks and the indexes to fetch?
- export a HTML representation of an NFT

These are just some ideas from the top of my head.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 22, 2020, 8:23pm UTC](https://forum.flow.com/t/extensibility/622/7 "2020-10-22T20:23:31Z")

</div>

With the example code at the top of the proposal I just meant to show how one could add extensions right now and demonstrate the issues that has. It is not meant to show the proposal’s outcome, and more specifically isn’t supposed to imply that extensions themselves are structures.

Sorry for the confusion, I might remove it.

As for containment of resources in Cadence in general, only resources can contain resources. Nothing would change about that with the proposal.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 22, 2020, 8:23pm UTC](https://forum.flow.com/t/extensibility/622/8 "2020-10-22T20:23:54Z")

</div>

> [@bjartek](#):
>
> - paying the original creator of an NFT a royalty on resale.
> - storing a signature for a given NFT (could be combined with the above)
> - storing ownership trail information (a NFT owned by somebody might be more valuable? Lets say I own a TopShot moment of Zion that he has owned himself?)
> - storing edition information for an NFT
> - formalize how to fetch onChain stored content. Might be possible to chunk up content into base64 batches and store a capability to the chunks and the indexes to fetch?
> - export a HTML representation of an NFT

Great use-cases, I’m adding them!

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 23, 2020, 9:58pm UTC](https://forum.flow.com/t/extensibility/622/9 "2020-10-23T21:58:46Z")

</div>

Some more thoughts / suggestions for answers to the open questions regarding declarations:

> Can extensions be referred to, i.e. do they have a name?

I think it would be useful to name extensions to have a way to identify / refer to a specific extension, especially when importing/using the extension. This would also allow the declaration of multiple extension in the same location and allow a user to selectively import them. For example (with straw man syntax):

```swift
extension Autograph for CoolNFT {
    fun sign(/* ... */) { /* ... */ }
}

extension Ownership for CoolNFT {
    fun addOwner(/* ... */) { /* ... */ }
}

```

In some other languages the extension functions are self-standing and the individual extension functions can be imported individually. Imports can then often rename the functions, which enables the use of multiple extension functions that have the same name.

Instead, I think we can handle conflicts by making the usage explicit at the call-site.

> Can and if so how are nested types extended, e.g. a resource declared in a contract?

I think this would be required, as currently it is not possible to declare top-level resources, they must be contained in contracts at the moment.

We could allow dotted identifier syntax to refer to a child declaration. For example, given a resource declaration `R` in contract `C`:

```swift
contract C {
    resource R {}
}

extension E for C.R {

```

> How are declaration conflicts handled? For example, if two accounts both declare a function with the same name, is it possible to import both, and if so how?

This could be solved by naming extensions, see above.

> Should it be possible to declare additional fields?

Yes, I think it would be very useful to store additional data.

I can’t find any precedence for this in currently popular general-purpose programming languages, but there should not be any reason to not allow this, except for this proposal also figuring out a way to handle field initialization, and if the field has a resource-type, destruction.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 29, 2020, 9:28pm UTC](https://forum.flow.com/t/extensibility/622/10 "2020-10-29T21:28:52Z")

</div>

Notes from the last call:

- It would be nice to extend interfaces:

- We want to promote and drive adoption of standard interfaces (conventions), to avoid fragmentation

- Idea for declaration syntax:

- It would be nice to provide a default implementation for interfaces:

- Ownership: Who owns / stores the extension’s additional data?

- Access in extension on extended type:

- Introspectability/reflection:

- Feature request for Cadence: object size introspection

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [October 29, 2020, 9:39pm UTC](https://forum.flow.com/t/extensibility/622/11 "2020-10-29T21:39:47Z")

</div>

Some topics related to extensibility came up in our calls, and I think it’s a good idea to quickly explain them. That way we can draw a clear boundary what we want to specify and discuss in this proposal and what is not part of it:

This proposal is regarding **extensibility** : extending existing types with additional data and functionality, retroactively, i.e. without modifying the original declaration.

What also came up in our discussions is **composability** : re-using existing code, proactivly (as opposed to retroactively in extensibility).  
This is very much something we also want to pursue in Cadence, but I think it’s a good idea to discuss and specify this in a separate proposal.

In addition, I think we should strive to keep the first proposal small, so that we can implement it more quickly and gather feedback on it more quickly.  
Though the feature ideas we have discussed so far are great, and we shouldn’t just ignore them, so I suggest extending the “Future / Out-of-scope” section with those items, namely:

- Composability
- Extensions of interfaces
- Default implementation for interfaces

---

<div class="post-metadata">

**Author:** ![bjartek](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bjartek/32/143_2.png) [@bjartek](https://forum.flow.com/u/bjartek)\
**Post date:** [November 1, 2020, 7:02pm UTC](https://forum.flow.com/t/extensibility/622/12 "2020-11-01T19:02:13Z")

</div>

So should we limit the MVP of this to something that

- cannot use private state of NFT you extend
- state for extensions are stored with the NFT
- you should need access to the resource in order to extend it, not just the reference to it.
  - so in order to sign it with moment they would need to transfer their NFT to moment, they sign it and then they transfer it back again.

The way I see it the following needs to be solved pretty early for NFTs on flow

- identifiers, are they going to be autoincrement and seperate for each kind of NFT?
  - should an identifier change if you store it in another collection?

- extensability (this proposal): the ability to add new functionality to and NFT retroactively and discover that new functionality.
- composability: the ability to reuse code across NFTS, so you do not have to write your own Borrow method or withdraw method
  - handling super() correctly here should also be considered.
  - naming collisions in interfaces

- standard NFT fields, in adition to the identifier mentioned above
  - name, description, content all as String would be enough to solve MANY scenarios.

---

<div class="post-metadata">

**Author:** ![bjartek](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bjartek/32/143_2.png) [@bjartek](https://forum.flow.com/u/bjartek)\
**Post date:** [November 3, 2020, 8:22pm UTC](https://forum.flow.com/t/extensibility/622/13 "2020-11-03T20:22:26Z")

</div>

- Access of fields, should only be allowed to view visible fields for extensions. public functions call them

- some extensions like signature should not be removable

- other extensions like kittyhat should be removeable. (use attach verb or say removeable extention)?

- only owner of resource should be allowed to remove attachements/removeables

- only owner of resource should be able to attach or extend an NFT

- what happends when you remove an attachment, you will get the resource back

- what happends when you destroy a resource that has an attachment/extension

- you should not be able to destroy an extension without destroying its owner

- should extensions be resource or be allowed to contain resources?

- should attachments be resource or be allowed to contain resources?

- should these capabilities be on NFT, Resource, or use a Virtual Resource and merge them as needed.

- the order of which you extend something matters. A kitty is signed and then framed, vs a kttiy is framed and then signed.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [November 13, 2020, 9:28pm UTC](https://forum.flow.com/t/extensibility/622/14 "2020-11-13T21:28:12Z")

</div>

Notes from our call on 2020-11-10:

- Last session

- Maks:

- start with extensions

- support for collections? e.g. multiple signatures

- ownership tracking / royalty extension:

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [November 13, 2020, 9:59pm UTC](https://forum.flow.com/t/extensibility/622/15 "2020-11-13T21:59:52Z")

</div>

Thank you again everyone for joining the last call and discussing the proposal. I have updated the proposal above as far as I could.

So far the calls have been very much in the form of brainstorming potential features and use-cases, so now it would be great to focus more on a concrete proposal, ideally an MVP that we can start to implement.  
However, there are still quite a few open questions that we need to answer before we can start implementation.

It would be great if we could all look at the outstanding questions and try to answer them.

For example, so far the proposal only defines that extension can add additional functions to extended objects, but we also discussed how we want to allow extensions to declare additional fields.

As I listed above, how are the extension’s fields initialized, and if they are resource-typed, how are they destroyed? Are extensions able to extend the destructor of resources with arbitrary code? This could prevent resource owners from destroying the extended resource

I’m happy to try an propose concrete answers to the open questions / solutions to the open problems, and then we can discuss and refine them to ensure they allow the use-cases we hope to cover.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [November 27, 2020, 7:40pm UTC](https://forum.flow.com/t/extensibility/622/16 "2020-11-27T19:40:46Z")

</div>

Notes from the last call:

- It would be nice to also have support for extending existing types with additional normal structs/resources/etc.,  
i.e. ones that don’t interact with the extended type:

- Using the extension statically:

- It should be possible to test if an extended type has a run-time type:

- Related: It should be possible to check if a run-time type is a subtype of another run-time type:

- Related: It should be possible to get the run-time type of a value.  
See [https://github.com/onflow/cadence/issues/195](https://github.com/onflow/cadence/issues/195)

- It should be possible to get the types of all extensions of a value,  
e.g. through a function on all types:

- Adding an extension:

- Handling conflicts:

- It should be possible to iterate over all extensions of a value:

- Extensions can also have extensions

- Removing an extension:

- How can removal be prevented?

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [November 27, 2020, 9:07pm UTC](https://forum.flow.com/t/extensibility/622/17 "2020-11-27T21:07:22Z")

</div>

Notes from our call on 2012-11-27:

- Can extensions be referred to, i.e. do they have a name?

- Can and if so how are nested types extended, e.g. a resource declared in a contract?

- How are the extension’s fields initialized, and if they are resource-typed, how are they destroyed?

- Syntax for type with extension?

- Does combination of multiple extension?

- Another idea for disambiguation:

- Syntax for adding extension? `extend` keyword?

---

<div class="post-metadata">

**Author:** ![blurden](https://avatars.discourse-cdn.com/v4/letter/b/f08c70/32.png) [@blurden](https://forum.flow.com/u/blurden)\
**Post date:** [December 30, 2020, 1:01pm UTC](https://forum.flow.com/t/extensibility/622/19 "2020-12-30T13:01:25Z")

</div>

Really excited about the work on this part of flow.  
One note, “trail of ownership” is known as “provenance” in the art world.  
Question - with the notion of dynamic artwork… a landscape whose time of day matches your location and thus the daylight changes with it. the idea that a work of art needs to be fed, else it looses say the saturation in it’s colors… would these fall into extensibility or composability?

---

<div class="post-metadata">

**Author:** ![sainati](https://avatars.discourse-cdn.com/v4/letter/s/f1d935/32.png) [@sainati](https://forum.flow.com/u/sainati)\
**Post date:** [August 15, 2022, 6:35pm UTC](https://forum.flow.com/t/extensibility/622/20 "2022-08-15T18:35:05Z")

</div>

Looking to start implementing this; is there somewhere I can view the alternative solutions that were used in the uses cases like CryptoKitties accessories or additional info on TopShot moments? It would be useful when designing a solution to make sure that the solution would solve the original use cases.

---

<div class="post-metadata">

**Author:** ![bastian](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.flow.com/bastian/32/183_2.png) [@bastian](https://forum.flow.com/u/bastian)\
**Post date:** [August 15, 2022, 6:45pm UTC](https://forum.flow.com/t/extensibility/622/21 "2022-08-15T18:45:44Z")

</div>

> [@sainati](#):
>
> is there somewhere I can view the alternative solutions that were used in the uses cases like CryptoKitties accessories or additional info on TopShot moments?

CryptoKitties / [KittyHats](https://kittyhats.co) was one of the first examples of extensibility on Ethereum. You can see the implementation, the Solidity contract, [here](https://github.com/kitty-hats/contracts/blob/ea48a68bc9d3939ca7f5d13dc0b2f724a2dba8bb/contracts/KittyItemToken.sol#L174-L186): The accessory token is attached to a kitty by storing the kitty ID in the token, i.e. it is a bottom-up approach.

This is a really good blog post explaining the bottom-up and top-down approaches (it is even using KittyHats as an example): [Top-Down and Bottom-Up Composables, What’s the Difference and Which One Should You Use? | by Nick Mudge | HackerNoon.com | Medium](https://medium.com/hackernoon/top-down-and-bottom-up-composables-whats-the-difference-and-which-one-should-you-use-db939f6acf1d).

[ERC-998: Composable Non-Fungible Token](https://eips.ethereum.org/EIPS/eip-998) specifies both approaches to support backwards-compatibility, i.e. existing contracts (which are immutable on Ethereum).

If we add this proposed extensibility proposal to Cadence, existing contracts would automatically gain support without any changes required by contract authors, which would obsolete the bottom-up approach, as the top-down approach could then always be used.