FLIP for Attachments

[dsainati1]

This FLIP is intended as an alternative to onflow/flow#1101, and should be considered in the context of the discussion on that FLIP, as well as in https://forum.onflow.org/t/extensibility/622 and onflow/cadence#357.

Please direct discussion on this FLIP to https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645

[turbolent]

Looks good! It would be great to comment more on the differences to the extensions FLIP, and what the advantages and disadvantages this proposal has over it.

[turbolent]

This initializer uses super - is this legal?

[dsainati1]

Yea; the initializer is run when the attachment is added, so super is safe to use here.

[joshuahannan]

This looks good to me! I like it better than extensions too. I just had one question about multiple attachments of the same type

[joshuahannan]

Can a composite type have multiple attachments of the same type?

[dsainati1]

Ah this is a good point; implicitly it would have to be no since the attachments are referenced/looked-up by type.

[joshuahannan]

I feel like that is going to be something that people will want.

[dsainati1]

Hmm, in any situation where someone would want to have two different attachments of type T on a resource, they could also make a TManager type attachment that contains a [T] field, and achieve the same effect with a little indirection.

[joshuahannan]

my prediction is that most attachments will probably want to support multiple per resource, and I think it would just be better for the get attachments method to just return an array of attachments of the requested type, even if it is only a one-element array. I think requiring there be a wrapper type around multiple attachments of the same type just makes things more difficult, because then if you want to find a specific attachment for a resource, you can't just request its type any more. you also have to know the type of the wrapper

[dsainati1]

Hmm, I think I am perhaps not following; can you give me an example of where resources would want to support multiple copies of the same attachment?

Keep in mind that attachments cannot be removed from resources without destroying them; i.e. they are not objects in and of themselves. In this iteration of the proposal, for example, the Hat would not be an attachment for the Kitty because the Hat should be an independently valuable resource that can be bought and sold independently of the Kitty itself. Hence, the attachment for Kitty would be a HatManager that keeps track of all the Hats present on that Kitty, while the Hats are just normal resources.

This paradigm also allows for more flexibility in the implementation of Hats, since they can be written agnostically of the details of the Kitty, and the HatManager that actually gets attached to the Kitty just operates as an interface between them. In fact, under this model any resource X can be "attached" to any other resource Y using an XManager attachment for Y.

[joshuahannan]

okay, that makes more sense