V1.0 other suggestions related to codes organization:

[duongphuhiep]

(1) To keep the "ore" package cleaner, we should move all the following struct outside the "ore" package

type c struct {}
type a struct {}
type simpleCounterUint struct {}
type simpleCounter struct {}
type simpleCounter2 struct {}
type counterGeneric[T numeric] struct {}

I suggest to move them to the "internal" folder, They will have a public Uppercase name in here but still not accessible from outside.

(2) Code samples in the documentations

• Except for the first codes example "Getting started" which we will put the full codes source to the markdown docs...
• Other codes example in the markdown doc should be bare minimal snippets codes which go straight to the point. So no "import" statement, no "func main()"... => just put directly the important snippet (which might be incomplete codes) to the doc.
• However, we will link to the full codes in the /examples folder. In other words, each codes snippet in the Doc should link to a full working codes in the examples folder. The corresponding working example will help to validate that the corresponding codes snippet in the doc could actually works.

(3) We will have to make sure that the examples work as well. Ideally, the github action pipeline should failed if the certain example doesn't compile.

(4) it is nice to have a documentation website supporting the "text search" button. It might require a lot of work, but would definitely attract more users.

(5) it is nice to have some convention on

• how should we organize thing? For example, I created a new type concrete struct, I'm not sure where to put it, should it be in ore.go or on concrete.go, util.go.. or when I created a new func, how to choose a good place for it
• how should we name thing
• this project is small, so this last point might not very important, we can just follow our "instinct", but it is still "nice to have" some base or suggestions...

[firasdarwish]

(1) resolved in 0.6.0
(2) partially resolved 0.6.0, still working on it
(3) resolved in 0.6.0
(4) i've been working on this for some time now, i'll finish and publish it once we have a stable API
(5) i'll write down a few draft suggestions so we could discuss them before committing, i'll be glad to hear your suggestions as well

[duongphuhiep]

0.6.0 is a fantastic release, congrat!

I feel like the file splitting is a bit too much. (I struggled a bit to find where is the RegisterSingleton() function, and end up using "Goto definition" from a test :D). I would group all the public "Get" to one file, all the public "Register" to other file...

Again it is subjectif, there is no right or wrong. This mater is related to the point 5.

I asked my friend "chatgpt" who suggest the following rule of thumb:
"Keep files logically grouped and under ~300-400 lines. Split them only when they grow too complex or contain unrelated logic."

[firasdarwish]

thanks @duongphuhiep , with your contributions we're getting closer everyday to a stable production-ready release!
i just released v0.6.1 with changes related to oreKey and other minor stuff
i'll dedicate more of my time in this stage to adding more tests and organizing the codebase