Deniz Mert Edincik

it is not pre/post condition problem. I changed the code. ``` **myContract Some Receiver Resourcer** self.savedftVaultReference = &Vault someContract.purchase(

> Now according to the above rule, this reference is still valid. In terms of a security perspective, I think this should be OK. This one is tricky, I agree...

I think the ultimate solution (to custom transactions etc) is to cover all mutations on the chain with transaction post conditions. But showing that in a user-friendly manner which my...

> One of the most asked questions in the discord server is "how do i know what user called this method". Instead of putting `&Identity` to function signatures, why we...

> We should emphasize that this feature should not be used for typical access control use-cases, and capability-based access control should be preferred. To be totally honest, when you have...

@bjartek i think this is really good btw. I meant there shouldn’t be push for capability when it is not needed. A lot of contract code can be simplified with...

@turbolent thanks for the review, I am planning to jump in tomorrow.

> @bluesign Would it be OK to commit some improvements to this PR, or would you rather like a separate PR against this one? Ofc It's ok. Just I am...

Thanks @turbolent, I think initializers and destructors are also can be needed but I am not sure about what can be the side effects there. ( So I think I...

> Totally agree with @SupunS here. If you can say default implement a destructor and destroy things and you forget to override that in your impl it can be bad....