Comments (13)
The "types" folder is there in place of putting all the files in the root directory. Keeping project-wide common types esp for external callers in the root directory is the standard convention for Golang. We want to keep the root directory clean, Makefile and Godep.toml etc., so moving every go file from the root directory to a special directory is IMO an improvement over existing Golang conventions.
@jaekwon Could you reference where this convention orignates from? Personally I've never seen this to be the case and even light inspection of popular Go projects shows a total different approach. If anything people are advocating for package division by domain, What are the main concepts, where do they interface, etc. And then have their types close to them and not remote in another place. To give some context the CodeReviewComments explicitely state to avoid meaningless package names.
Some more thoughts on packages:
As a rule of thumb, keep types closer to where they are used. This makes it easy for any maintainer (not just the original author) to find a type.
In go, package names are not plural.
In the end I don't feel strongly about this issue because I want to see conventions, best-practices or the soup du jour being followed, but I strongly believe that this has real implications on the quality and complexity of the software we write. As we would benefit from the constant conversation how something fits into the domain and what it exposes to the world.
from coding.
@liamsi Exactly that, sorry for failing to provide proper reference, amended
from coding.
https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1
from coding.
I don't feel so strong about the types
that I would call it an anti-pattern. But I do agree with every concern @xla raises above. As someone who is new to the code base, I found the name of the package confusing, as I was expecting something related to an internal type system. It's difficult to guess from the package name what the structs in types
are used for.
As far as I understand, the structs there are the ones which will be send around via JSON / amino? Is that correct? If so, why no call it messages
(or aminos) and move everything which isn't send around into other packages?
from coding.
I'm not sure I understand what you mean by types
. Do you mean a package like this: https://github.com/tendermint/tendermint/tree/master/types ? If not, could you provide an example?
from coding.
Eager to hear your strong opinions/ alternative designs to the types package. I think in the context of the SDK - types is nice explicitly for when trying to reference an interface. If we limit the implementations of the types to outside of the types package I'd imagine it's a maintainable and safe development pattern.
I imagine that clumping to much into a single package could raise issues down the road (thoughts here?) - but also I to much package (and file) separation can be a real hassle to work with and create obfuscated code bases which are difficult to navigate and understand - which is a real issue.
from coding.
@melekes The article doesn't mention a types package, rather talkes about a root package and sub-packages.
from coding.
Yeah typically the design pattern I've seen is where folks use the root directory kind of like a types package, What's your opinion on this @xla vs straight up types/
directory?
from coding.
IMHO there is only one valid application of the a package called types
and that is the one that standard lib offers: https://golang.org/pkg/go/types/ as it concerns itself with the language native concept of a type.
Resorting to something like types
seems as weak as a package called util
, ultimately doomed to be a bucket where anything is dumped into as it seems too hard at the time to figure out where it actually belongs. Packages are encoded boundaries of the domain and most likely your domain would not be concerned with types. Furthermore will it open up this massive namespace which adds additional bookkeeping overhead for the people working on the codebase:
types.FooBar
types.FooBaz
///
foo.Bar
foo.Baz
My point is that when using something as generic as types
you take away an important dimension of code organisation and communication of intend.
Eager to hear your strong opinions/ alternative designs to the types package. I think in the context of the SDK - types is nice explicitly for when trying to reference an interface. If we limit the implementations of the types to outside of the types package I'd imagine it's a maintainable and safe development pattern.
In reality types seldomly stand in isolation and are almost always bound with functionality, which end up in the same package, which leads to that code needed to be tested. If we assume that the Dependency inversion principle has any value then ideally interfaces should be declared where they are needed, while there are strong examples of widely used interfaces, e.g. io.Reader
, their surface is so small that a package depending on it could easily declare it in place. Which is a desirable characteristic anyway to ensure that the scope of an interface doesn't blow up.
from coding.
@liamsi lol we need need to name something "aminos" way to amazing
from coding.
Disclaimer: Cosmos-SDK Centric
CC: @sunnya97
@xla great point about the additional namespace overhead - totally with you on that one. Not sure what this looks like in tendermint but in the SDK there actually ARE "types that stand in isolation of functionality". In this situation the types are defined in the sdk and utilized by independent modules (with the intention of being able to mix/match swap out modules) - So in this particular instance - I actually feel that it makes sense to have these high level type definitions (intended to be fulfilled by arbitrary modules) separated from their functionality. For everything else that is not explicitly what I just mentioned I whole-heartedly agree that it doesn't belong in the types/
-> and this does currently exist. I'm thinking that all these pieces of functionality (typically small amounts of logic) should exist in unique packages maybe clumped together in a common folder aka common/yourpackage/
What are your thoughts on that?
from coding.
The "types" folder is there in place of putting all the files in the root directory. Keeping project-wide common types esp for external callers in the root directory is the standard convention for Golang. We want to keep the root directory clean, Makefile and Godep.toml etc., so moving every go file from the root directory to a special directory is IMO an improvement over existing Golang conventions.
"util" is a catchall for internal implementations and it does get unwieldy. But the SDK itself IMO should have a catch-all package called "sdk" where a lot of common interfaces/structs live.
Handler, AnteHandler, FeeHandler, Context, Address, Account, AccountMapper, Coin/s, Error, StdSignature, Tag/s, Tx, Msg, StdSignDoc, and all the store interfaces, I believe they should be referred to as "sdk.*" so we can standardize around these common interfaces and structures. They're all common elements that one needs to know about to fully grasp the SDK, as the SDK is built today.
It's true that others can build alternative systems using the components we've already built... like a ParallelBaseApp (Sunny's suggestion). But that shouldn't prevent us the SDK having specific opinions today that get someone started on building a kickass app. Most people don't need parallel tx processing. The types defined in "types" and the opinions that it represents, should be sufficient for the majority of uses-cases.
BaseApp should be the structure that users embed in their CustomApp. So BaseApp should embed IAVLApp, that seems fine. IAVLApp can live in cosmos-sdk/iavlapp or something. So we can have /baseapp and /iavlapp.
from coding.
cool thx
from coding.
Related Issues (20)
- deprecate `--root` from the stack HOT 3
- makefile standard HOT 2
- less bash scripts HOT 1
- Dist fuzzing - dist process should not be so deterministic. HOT 1
- Github label system HOT 9
- tools/Makefile standard HOT 2
- Reorganize Me
- Add discussion on CodeCov in github branch section HOT 1
- `make check` should fail if minimum versions aren't met HOT 1
- new name for make get_vendor_deps HOT 7
- consistency for where spec is location in a repo HOT 1
- handling funcs that return errors that are always nil
- Write a specification for our specifications HOT 1
- Prefix issues with what module they affect HOT 3
- Add a proposal-accepted tag HOT 6
- Automatic Changelogs HOT 10
- GitFlow HOT 4
- Design Patterns & Language HOT 2
- an install script for the whole stack
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coding.