eosdac / eosdac-contracts

All the EOSDAC smart contracts
MIT License
19 stars 11 forks source link

Create libeosdac #44

Open michaeljyeates opened 5 years ago

michaeljyeates commented 5 years ago

Move the _contract shared headers into its own library which contract developers will be able to include without copying them from our repo

We can also add action_wrappers to all the actions, so they can be used with the new interface

michaeljyeates commented 5 years ago

Dallas : I like the idea of shared library code which has all the sharable headers and functions in there and that was the whole reason that I made a _contract_shared_headers folder but I'm wary of putting too much in there unless we think it will not change (or we can abstract away the change within a method implementation). As soon as we create a shared library of re-usable code we need to be very careful with versioning (eg. semantic versioning for developers) and it will be also need to be in a git submodule which adds a little more friction for us too since we will also be consumers. I have been following the guideline that if another one of our contracts needs something from a contract then it should be in the shared folder otherwise I have not shared it. It's easier to add stuff than it is too take them away.

michaeljyeates commented 5 years ago

I think that we should at least put in all of the tables into shared headers into contract grouped files. Then we need to have a consistent naming scheme for them (I suggest [plural type]_table). If there are changes then we can increment the type name.

ie. we could have eosdac::custodian::custodians_table

michaeljyeates commented 5 years ago

Then some common functions could be added. Potentials are:

get_balance get_stake assert_valid_member

michaeljyeates commented 5 years ago

Another possibility for actions which assert is to create new actions which only assert. Then external contracts could inline that action.