You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before starting with any new feature I would like to clear and reorganize the code a little bit, so it would be more GO like and less C/Python like.
I don't want to impose my point of view or criticize as the whole idea and code looks handcrafted.
This is well done but rather lacks gopher polish. I am afraid it can make adding new features hard and clunky.
But with a few fixes, I think it can make it testable, organize it in a way that the package will depend on abstraction rather than on implementation. Then it will be able to decouple some parts and focus on improving performance if needed.
The success of the package lies in how easy it feels for developers to write code without all the time referring to the documentation.
I would propose to start from the simplest and then go for the hardest:
Make a feature branch so the above can be worked on independently not blocking any development.
Rewrite names (func, vars, definitions and docs) to be written according to GO standard.
Restructure code so public dependencies are well documented and depend on abstraction rather than on implementation so the package user may inject its own custom solution or we may provide more than one implementation available in easy to use way.
Write tests and benchmarks.
Each step will have a separate branch rooted from the feature branch.
Feature branch will be then merged to the main branch after the whole feature is accepted.
WHY IT'S IMPORTANT.
This project is still in the early stage of development and has potential. After decoupling some logic we may know which part needs improvement.
This will unlock more possibilities for the package user.
This will allow creating smaller binaries as the package user will have more freedom in choosing what goes to the project she/he is working on.
Please let me know if and how it is possible.
Thanks. 👍 job.
The text was updated successfully, but these errors were encountered:
Before starting with any new feature I would like to clear and reorganize the code a little bit, so it would be more GO like and less C/Python like.
I don't want to impose my point of view or criticize as the whole idea and code looks handcrafted.
This is well done but rather lacks gopher polish. I am afraid it can make adding new features hard and clunky.
But with a few fixes, I think it can make it testable, organize it in a way that the package will depend on abstraction rather than on implementation. Then it will be able to decouple some parts and focus on improving performance if needed.
The success of the package lies in how easy it feels for developers to write code without all the time referring to the documentation.
I would propose to start from the simplest and then go for the hardest:
WHY IT'S IMPORTANT.
This project is still in the early stage of development and has potential. After decoupling some logic we may know which part needs improvement.
This will unlock more possibilities for the package user.
This will allow creating smaller binaries as the package user will have more freedom in choosing what goes to the project she/he is working on.
Please let me know if and how it is possible.
Thanks. 👍 job.
The text was updated successfully, but these errors were encountered: