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
This is a roadmap to 2.0 which will also be a partial rewrite of the codebase (mostly a restructure). There are many open issues that the current codebase makes difficult to implement and test properly - due to the monolithic nature of each component.
v2 will involve a much more idiomatic Go package structure with use of interfaces. Back when I first wrote sampctl, Go was still a relatively new language to me and interfaces were the one remaining language concept I didn't have enough confidence in to use in a widely used tool.
The biggest proposed change is the introduction of the Dependency Interface. This means writing the same code and using the same dependency resolution algorithm for all components, not just Pawn source:
This will require gathering together all the attributes of these assets in their current form and modelling a generic "Dependency" (or "Node", since it's a tree...) structure which can then be implemented for each of these types.
I'm thinking this will likely be a good first pass:
typeResourceinterface {
Version() (versionstring) // The resource versionCached(versionstring) (isbool, pathstring) // Get cached path is presentEnsure(version, pathstring) (errerror) // Acquire if necessary
}
This should work for Git repositories, GitHub release assets and arbitrary HTTP file downloads. Which covers all of the above mentioned types of dependency.
The text was updated successfully, but these errors were encountered:
So what you are saying is, that every type of dependency should implement the resource interface, which allows a very fine control of how each dependency should ensure, and cache itself.
Could you go into further explanation of how you expect a node based pattern to be used here?
This is a roadmap to 2.0 which will also be a partial rewrite of the codebase (mostly a restructure). There are many open issues that the current codebase makes difficult to implement and test properly - due to the monolithic nature of each component.
v2 will involve a much more idiomatic Go package structure with use of interfaces. Back when I first wrote sampctl, Go was still a relatively new language to me and interfaces were the one remaining language concept I didn't have enough confidence in to use in a widely used tool.
The biggest proposed change is the introduction of the Dependency Interface. This means writing the same code and using the same dependency resolution algorithm for all components, not just Pawn source:
This will require gathering together all the attributes of these assets in their current form and modelling a generic "Dependency" (or "Node", since it's a tree...) structure which can then be implemented for each of these types.
I'm thinking this will likely be a good first pass:
This should work for Git repositories, GitHub release assets and arbitrary HTTP file downloads. Which covers all of the above mentioned types of dependency.
The text was updated successfully, but these errors were encountered: