-
Notifications
You must be signed in to change notification settings - Fork 668
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
Moving un-opinionated types and utilities outside of FRAME where possible. #211
Comments
Maybe |
I'm not convinced. If you need it somewhere else, just copy it. The nice use case of PBA frameless runtime isn't worth moving around stuff that we don't need anywhere else. |
(At some point we will have do to some cleanups of |
Did you see that I mentioned a second usecase? We're working on a utxo-based runtime framework.
If an |
The link didn't worked this morning (was the same docs.rs link). Just copy the macro. I don't see the problem. It is only ~6 lines. This is really nothing that requires an issue or too much discussion.
|
I don't fundamentally agree with this. If anything I would say Substrate's ideology is "we do what is semantically correct" to the extent that I know. For example, we have all of these complicated names (eg. instead of calling everything Transaction we have 3 words) for the reason of "we name things such that they best explain what they are", not convenience. Similarly, I think we should "place things where they are best suited", not where they are most conveniently used. Either way, I agree that copy pasting works for small things. And it is indeed not a big deal or blocker for anyone. But I'd like to keep a list of things that are not semantically part of FRAME, but are possibly useful outside of it, and as we refactor So far, other than
If you don't strongly disagree, let's reopen this, and let it be a tracking issue of items that we think should move to outside of FRAME. |
frame_support::ensure!
macro is useful outside of FRAME
And the derive macros, |
These macros are good examples of things that could be moved out into their own crate somewhere else. They would probably need some love to make them more flexible, but good in general.
These are FRAME layers around the bare host functions. While maybe others will use the same way to keep track of layers etc, I can also see other implementations that store the number of layers just in memory. Just because something looks like it could be moved into some general place, doesn't mean it should be done this way. |
The most important one I've found so far: the I want to implement this trait for the Tuxedo Executive, which is analogous to the FRAME executive. Perhaps it should live in sp-runtime? |
Just copy it. This is just FRAME internals. You already copied all the macro code for |
I'll continue copying stuff for now as I've been doing.
It's true that I've copied large swaths of your code in my initial attempt to make the Tuxedo runtime work as a parachain. I was thinking of that as the learning and hacking phase though. I was hoping that after I had something working by hacking up your code, there would be some common logic to be extracted into a nice general My reasoning is that the Substrate APIs themselves (especially, Core, BlockBuilder, TransactionPool) are designed to be flexible enough to accommodate many different runtime paradigms, so perhaps the Do you think this is an impossible or impractical goal or bad design direction? |
The |
I'm totally in favor that you are doing all of this and I think it is a great work. Having a different runtime language. However, just because things are done in FRAME in the way they are done and you also can do the same in tuxedo, doesn't mean that any other implementation would benefit of this. |
I started moving the |
UPDATE: #211
The
ensure!
macro is useful for checking assumptions in runtime logic. Because most runtimes are currently written in FRAME, this macro has found a home inframe_support
.However, this macro and others are useful in non-frame runtimes as well. I've encountered this issue when helping students write minimal frame-less runtimes at the Polkadot Blockchain Academy, and also while working on the Tuxedo grant.
I propose that we move this macro to somewhere less frame-specific, but I'd like guidance on where that may be. One idea is a new crate called
runtime_support
. But I'm open to other options as well. Once we agree on where to move it, I'm willing to make the PR.The text was updated successfully, but these errors were encountered: