Ooops: This should read
It simply does *NOT* influence the one and only package rule. On Thursday, 15 November 2018 09:04:01 UTC+1, Volker Dobler wrote: > > 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 (<[email protected]>) >> 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 <[email protected]> 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 (<[email protected]>) >>>> escribió: >>>> >>>>> It's already removed on SO. >>>>> >>>>> On Wed, Nov 14, 2018, 20:00 Victor Giordano <[email protected]> >>>>> 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 [email protected]. >>>>>> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
