Fairpool is a DEX for personal tokens. Create your own token & receive royalties from trading volume. Increase volume by offering dividends / selling content for your token. Subscribe to our Telegram / Twitter to get notified about updates.
Weekly progress
- ⚒ Worked on the code actions (faster way to write code).
- ⚒ Worked on our decision-making system.
Configurable functions
We’ve found a better way to enable customizations for code actions.
Suppose there are three functions: A, B, C, such that function A calls function B, and function B calls function C. It is easy to see that function A implicitly calls function C (without explicitly mentioning it). That means if the function C changes, the function A may change, too. This is a problem because it may block the effort to change the function C due to desire for compatibility.
There are three ways to solve this problem:
- Write a new function D (a fork of the function C), then manually rewrite the call sites to use the function D instead of function C.
- Implement functions A and B in a modular way: instead of explicitly calling the specific function C, modify them to accept function C as a parameter. This way, the code that calls the functions A or B would have control over which function should be used.
- Implement a global lookup table for different functions (so that it would be possible for the calling code to replace specific implementations without affecting the others).
We see that approaches #2 and #3 still require the developer to write a new function D (just like approach #1). We also see that approach #3 is just a global version of approach #2.
However, we note that with long chains of calls, approach #3 is the only viable one. For example, if the developer wants to change a function that’s 5 levels deep in the call chain, he/she would have to rewrite the whole chain with the approach #1.
The approach #3 is supported by certain languages out of the box. For example, Rust has traits, while Lean and Haskell have typeclasses. Rust traits are less generic than typeclasses but are quite powerful too.
We believe this problem is more important than it looks. For example, if the developer X doesn’t like how the function C works, he/she has the following solutions nowadays: a) fork the entire repo, make a change b) ask the developer Y (maintainer) to make the change. In the first case, developer X loses the future updates from developer Y. In the second case, developer Y has to understand the developer X’s use case and make a decision — whether the change is worthwhile or not.
In our case, as we’re building the code actions, we see that different developers have their own code styles, so our code actions have to be adaptable. We’ll try to use approach #3 to the fullest to allow other developers to customize the actions as much as possible.
Next week’s focus
- ⚒ Develop our decision-making system.
About Fairpool
Fairpool is a DEX for personal tokens. Create your own token & receive royalties from trading volume. Increase volume by offering dividends / selling content for your token. If you want to get notified about updates to our products, please follow our Telegram & Twitter.
Any questions? Reach out to us:
Website: fairpool.io
Telegram: @FairpoolDEX
Twitter: @FairpoolDEX
Anchor Podcasts: @FairpoolDEX
Medium: fairpool-dex.medium.com
$FAIR token: Uniswap
