Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create libeosdac #44

Open
michaeljyeates opened this issue Sep 1, 2019 · 4 comments
Open

Create libeosdac #44

michaeljyeates opened this issue Sep 1, 2019 · 4 comments

Comments

@michaeljyeates
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Then some common functions could be added. Potentials are:

get_balance
get_stake
assert_valid_member

@michaeljyeates
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant