About source folder organization

[Victor Giordano]

hello gophers!! how you doing? 

Some time ago i posted this in other CoP (community of practices),  don't go ahead wihtout reading the above two lines (or four and you get a thanks for free :P)

At first place that post doesn't get understood by the community over, so i edited to be far more than clear.

if you want, take some minutes, and read it, and, i will be expecting your opinion as a collegue.

Thanks in advance!

V

[Jan Mercl]

It's already removed on SO.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-j

[Victor Giordano]

Hello jan!

So, what are you trying to say is that you follow the link and see nothing?

[Jan Mercl]

Yes, that's it.

I see:

"This question was removed from Stack Overflow for reasons of moderation. Please refer to the help center for possible explanations why a question might be removed.

..."

--

-j

[Victor Giordano]

Thanks Jan. Then i shall paste the question here. I copy paste the question as it was writed at first place in order to honor an idempotent behvaiour (recall that the question was edited in stackoverflow for improving understanding). Thanks in advance for all that take the time for reading!.

Original question

The motivation behind this question is to obtain feedback of the commutity (specificially the golang devs) about something that keeps me wondering. The question itself is related to source files organization in a software , something that is an affair of every programmer that works in "industrial-strength software" (to quote my Dear Graddy Booch). In this case i sit over a project that employs golang as server programming tool.

Let's starts assuming that there is a lots programming concepts out-there that are language agnostic, i mean they do not belong to an specific language; for example the one thing i'm pointing out here: laying out the source files accross folders, is not something that is exclusive to a particular language.

Due to the hierarchical nature of file system, i would expect that others persons also wonder what about the meaning of those files across the folders, there is a reason for laying out the files in specifics folder right? (i wonder)... or, sitting on the opposite side of thinking, shall we put everthing on a single folder?... i mean, c'mon... we know the answer. No single folder as it's not quite good for growing projects.

It is says that in golang packages doesn't follow any hierharchy, but the source files relies on a concrete hierarchical file system. So there is grey area here for a person that see the whole image, because package doens't follow hierchary but the source files yes, and, after all we work over source files. So after inspecting some source codes of the authors of the language (https://golang.org/src/) i do notice that from a parent package there is no reference to any child pacakge. Although i do not make an exhaustive exploration of the source files, i started to wonder if that actually says something about how people think (in a golang based project, important detail), basically, how we think. It could be taken as a rule thumb? I Mean for example stating something like this: "devs tend to not reference package implemented in subfolders of the same hierarchy". I mean, that is something (actually a lot), at least for me. Let me put this on these words: it is saying that the abstractions (or exported members) located in "parent" packages doesn't know any of the astractions located in "childs" packages, or at least, not directly. And i would say that this could be seen as a design principle.

What are "parent" and "child" package:

I'm talking about two "kinds" of packages, parent and child. Parent is the one located in a directory (parent) and child is one located in a subdirectory of the former (parent/child). Plese forgive if my words aren't addecuate, focus on the concepts. For those that never work with packages outside golang, try to bear with me and allow me to use those inappropriate words for trying to explain.

I'm editing this question because i do think that mi intend was not so clear, my intend is to gather other devs feedback about this, if they ever wonder it; so the answer could answer yes, maybe no, maybe you don't care about it because never stop to reason about it or see a pattern. I do not know if the question is opinion based or not, but i guess is pretty clear my point, i mean the kind of feedback, and eventually, and answer of course (that may can be built together, why not? its not the sum of relativities the absolute true? (Chuang Tzu). I think these thoughts should be written somewhere, after all, it is knowledge about something, i guess here will fit better for a start)

I would like to hear other devs thoughts about this, perhaps i'm the first person on the comminity to point this out (but surely not the only one who thought about this), and viola!!

I'm eager to read your feedback.

[Jan Mercl]

On Thu, Nov 15, 2018 at 1:38 AM Victor Giordano <vituc...@gmail.com> wrote:

example.com/foo can import example.com/bar: siblings vs "parent" and "child".

example.com/foo can import example.com/foo/a but in the same time example.com/b can import example.com: "parent" and "child" meaning can be inverted or not.

The conclusion is that there are no "parent"/"child" packages or "subpackages". Just packages that import other packages. It's true that the dependency graph must be a tree (acyclic), but that tree is independent of the import path hierarchy.

--

-j

[Jan Mercl]

On Thu, Nov 15, 2018 at 8:52 AM Jan Mercl <0xj...@gmail.com> wrote:

Fixing it

example.com/foo can import example.com/bar: siblings vs "parent" and "child".

example.com/foo can import example.com/foo/a but in the same time example.com/foo/b can import example.com/foo: "parent" and "child" meaning can be inverted or not.

--

-j

[Volker Dobler]

My opinion on this: You are overthinking it. A lot.

Let's start simple. Cyclic dependencies between packages

are disallowed and whatever you do you packages must not

for an import cycle. This is the only hard rule. Note that this

rule is totally decoupled from the filesystem layout of your

packages.

The last point already hints at why I believe you are overthinking

the importance of the file system layout: It simply does influence

the one and only package rule.

Well, almost. There are two (I hope I did not forget one) special

file system folder names: "internal" and "vendor" and these do have

special semantics on how package lookup works. But these are

not at the heart of you question as far as I understand your question.

For the rest: Package spread on the filesystem is guided by the

following aspect:

You import by file system path so this hierarchical path can

be used to transport information to the reader of your code:

    import "net/http/cookiejar"

and

    import "household/kitchen/cookiejar"

will bot import a cookie jar but what type of jar this will be is

nicely explained in the file system path.

The file system also lets you group stuff that belongs together

logically or how it is used. Peek at the stdlib: In folder

encoding you will find lots of different encodings.

Note that this is a logical grouping and not a technical.

There are no "parent" and no "child" packages in Go. Do not

think about file system layout as parent/child, top/sub, whatever.

It is not. It is file system layout. Just like you would organize

your documents: You might do

documents/house/official to store bill of sale and property tax

and and documents/house/bills/garden to keep your landscapers

bills while putting general stuff into documents/house to keep

the separate from documents/school. You organize, but this does

not introduce a parent/top/abstract - child/sub/concrete relationship

between these documents.

Filesystem layout is (apart from internal and vendor) to group

packages logically and not technically. Do not overthink it.

V.

[Volker Dobler]

Ooops:

This should read

It simply does NOT influence the one and only package rule.

[Victor Giordano]

Hello Volker! Thanks for your feedback.

The overthinking is direct consecuencie of two things: having time and don't have TV at home :P. 

I have a felling that what you are trying to say me is to: just forget a little bit over the underlying storage system for the files, and focus only in the package concepts as an abstraction, and the only "hard" rule they have is that they can not be referenced in a circular fashion. Thas is ok!. I got it.

You may say that i'm a little stubborn but what after i look at others source files i do notice that they do not reference "childs" packages from "parents" (please allow me to use those words, again...)or can you tell me of the opossite thing? I mean, someone or a project that actually constains at least a source file that imports a package located in sub directory.  If nobody uses that pattern that may say something about how "we work" (you probably say that i overthing a lot, but for me i'm realizing observations over other people work). What i may try to discover here is a, you may call it, "soft" rule. BTW: Recall that packages introduces namespaces, and namepsaces are important for code organization.

V

[Jan Mercl]

On Thu, Nov 15, 2018 at 4:51 PM Victor Giordano <vituc...@gmail.com> wrote:

> You may say that i'm a little stubborn but what after i look at others source files i do notice that they do not reference "childs" packages from "parents"

> (please allow me to use those words, again...)or can you tell me of the opossite thing? 

For example here: https://github.com/golang/go/blob/master/src/regexp/regexp.go#L70

--

-j

[Victor Giordano]

Thanks for pointing that out.

V

[Victor Giordano]

For your information people, i'm trying to open my mind for embracing the concept of packages without any trace of the hierarchical relation of underlying file system in mind!

Thanks again for your valuable opinions. I really needed someone to talk about this, i love doing code/patterns/idioms teraphy!.

V

[Victor Giordano]

Jan, Volker... i will try you to summon over here!

There is another person with some kind of the same problems i were... he is trying to organize code in packages and maybe overthinking.

--