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.
On Thursday, 15 November 2018 01:38:52 UTC+1, Victor Giordano wrote:
>
> 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.
>
> El mié., 14 nov. 2018 a las 16:40, Jan Mercl (<0xj...@gmail.com
> <javascript:>>) escribió:
>
>> 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.
>> ..."
>>
>> On Wed, Nov 14, 2018, 20:37 Victor Giordano <vituc...@gmail.com
>> <javascript:>> wrote:
>>
>>> Hello jan!
>>> So, what are you trying to say is that you follow the link and see
>>> nothing?
>>>
>>> El mié., 14 nov. 2018 a las 16:07, Jan Mercl (<0xj...@gmail.com
>>> <javascript:>>) escribió:
>>>
>>>> It's already removed on SO.
>>>>
>>>> On Wed, Nov 14, 2018, 20:00 Victor Giordano <vituc...@gmail.com
>>>> <javascript:>> wrote:
>>>>
>>>>> hello gophers!! how you doing?
>>>>>
>>>>> Some time ago i posted this
>>>>> <https://stackoverflow.com/questions/52299826/is-bad-practice-to-reference-a-parent-package?noredirect=1#comment91548071_52299826>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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 <javascript:>.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>>>
>>>> -j
>>>>
>>> --
>>
>> -j
>>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
