Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

You may forgive me. El jue, 16 nov 2023 a las 11:57, Mike Schinkel () escribió: > On Thursday, November 16, 2023 at 9:16:22 AM UTC-5 Victor Giordano wrote: > > Lads, I guess this entry <https://go.dev/tour/methods/6> and the > subsequent entries are very important regard

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

Regarding the Original question: I guess the advice of using a pointer receiver can be OK as long you know what you are coding. quoting "https://go.dev/tour/methods/8"; > There are two reasons to use a pointer receiver. > The first is so that the method can modify the value that its receiver p

Re: [go-nuts] Can Generics match implementers of an interface?

ottom, allowing me to express freely and I'm thankful for that. El mar, 24 oct 2023 a las 14:51, Axel Wagner () escribió: > On Tue, Oct 24, 2023 at 6:14 PM Victor Giordano > wrote: > >> TD;DR: The above is just a stream of consciousness that I release in this >> place t

Re: [go-nuts] Can Generics match implementers of an interface?

TD;DR: The above is just a stream of consciousness that I release in this place that I find appropriate for this purpose. Forgive me in advance. This is the thing about generics... make the world a very complex place.. and I do wonder... ¿ What kind of problems can be solved by generics that can n

Re: [go-nuts] Can Generics match implementers of an interface?

TD;DR; Erratas: I mean, I got all the genericity (not "generosity") I need (without "I shall") I'm sorry and please accept the amendment. El lun, 23 oct 2023 a las 18:21, Victor Giordano () escribió: > Yes Ineed Mike! Generics can be good and can be bad... perhaps j

Re: [go-nuts] Can Generics match implementers of an interface?

ttps://groups.google.com/g/golang-nuts/c/eD7207kM8zA/m/IZSZNPwnAQAJ> > why that was not sufficient for the use-case earlier in the thread. #justfyi > > On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote: > >> Very interesting case. >> >> As Alex say

Re: [go-nuts] Can Generics match implementers of an interface?

Very interesting case. As Alex says, if you "help" the compiler writing the actual type parameter like `Append[Suiter](slice, suiter)` it works. I have seen this before in Java when generics comes into town... I guess with time golang team with time will improve the type inference engine... th

Re: [go-nuts] Re: About allowing conversion from bool to int

than against.. Perhaps there will be any slight change to consider or cast a votation sometime in the future..? Thanks for your patience!.. Greetings El vie, 20 oct 2023 a las 21:31, Ian Lance Taylor () escribió: > On Fri, Oct 20, 2023 at 2:14 PM Victor Giordano > wrote: > >&g

Fwd: [go-nuts] Re: About allowing conversion from bool to int

-- Forwarded message - De: Victor Giordano Date: vie, 20 oct 2023 a las 19:09 Subject: Re: [go-nuts] Re: About allowing conversion from bool to int To: Volker Dobler Volker I'm very grateful for your answer! Thanks!!! > A lot of people (me included) do not see this c

Re: [go-nuts] Re: About allowing conversion from bool to int

;> I use 1 a lot and 4 (or the suggested bool<-->int conv) never. >> I have no idea what you want to express with 2 >> and 4 addresses a kind of problem that has no >> simple solution like a one-line function. >> >> V. >> >> On Friday, 20 October

Re: [go-nuts] Re: About allowing conversion from bool to int

idea what you want to express with 2 > and 4 addresses a kind of problem that has no > simple solution like a one-line function. > > V. > > On Friday, 20 October 2023 at 15:12:06 UTC+2 Victor Giordano wrote: > >> Hello fellow gopherships... ¿How you doing? >> >> Ho

[go-nuts] About allowing conversion from bool to int

Hello fellow gopherships... ¿How you doing? Hope just fine! A week ago I proposed to allow conversion from bool to int, assuming false to 0 and true to be 1. This was the proposal and I do appreciate a lot the polite responses from Ian. I pick my p

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

the mass of my fellow > developers. > On Saturday, September 30, 2023 at 11:59:36 PM UTC+2 Victor Giordano wrote: > >> *Alex*, your second reply was even more powerful in terms of feelings >> and ideas to work with in order to embrace the change. Probably I'm >> str

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

. > > On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano wrote: > >> Thanks Alex, your insight was very helpful. >> >> Allow me to share the feeling I have => I still struggle a little in my >> mind... I craft web fronts in javascript, and back

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

and for those > that are, it seems that empirically, the new rules will align more closely > with what people expect subconsciously. > > I don't think you should worry too much. Run your tests with the new loop > variable semantics in Go 1.21 to see if everything still works. Most &

[go-nuts] About variables have per-iteration scope instead of per-loop scope

Hi gophers! How you doing? In my work we recently discuss with a buddy about this article . I need to talk about this I appreaciate that golang makes a lot of effort on this. Working with clousures cames with perils and the go vet tool emiting a warning

Re: [go-nuts] Re: Error handling

Ok, that is a point to have in mind. El vie, 4 ago 2023 a las 10:37, Miguel Angel Rivera Notararigo (< ntr...@gmail.com>) escribió: > I understand, but there is a little difference, you can find code out > there improving performance thanks to generics, I am not sure if we can get > any performan

Re: [go-nuts] Re: Error handling

ould be simpler than Go. > > As I said, I like the proposal, but I have learned that some times, I have > to accept things are not always as I want them to be. > > On Fri, Aug 4, 2023, 08:58 Victor Giordano wrote: > >> As far as I see things there is always room for change

Re: [go-nuts] Re: Error handling

As far as I see things there is always room for changes... but changes doesn't come without some resistance.. That is natural... > Go best features is the lack of new features. What about generics? That was a major change... It was really necessary or not is another topic. El vie, 4 ago 2023 a

Re: [go-nuts] Error handling

Yeah.. I mean, the "idiom" `err != nil return` err is something of the language. I complain about the boilerplate that idiom produces and that is fact fact (no one can deny it). You know, your approach implies making the language a little more complicated as new ways to deal with errors appear. I

Re: [go-nuts] Re: Error handling

I think that the original Author has made a clear point. It has no sense to denied that we often write a lot of times things like... if (err != nil) { return err } So, I understand that some people doesn't bother about that, and that is okey. *But for those that doesn't like to write someth

[go-nuts] ¿ Where is the source code of atomic.AddInt32?

Hi there! Hope you are having a great weekend (This is actually friendly greeting and you may greet me as well, it will be more than welcome) I reach this line and that is folks! [image: That's All Folks!

Re: [go-nuts] Importing a package declared in the root directory of a module

"a_module_path" > > var foo = util.Foo > > - sean > > On Sat, Apr 15, 2023, 20:40 Victor Giordano wrote: > >> Thanks *Sean!!* >> That makes sense for me! >> >> But i guess I must import with an alias as import without an alias >> doesn&#

Re: [go-nuts] Importing a package declared in the root directory of a module

Liao escribió: > import "a_module_path" > > optionally rename it to make it clearer > > import util "a_module_path" > > - sean > > On Sat, Apr 15, 2023, 20:31 Victor Giordano wrote: > >> Hi there! >> >> I was playing a little bit with module

[go-nuts] Importing a package declared in the root directory of a module

Hi there! I was playing a little bit with modules and packages, regarding making projects. And I'm struggling to use a package (non-main) declared in the root directory.. allow me to show an example: This scenario, I have project somewhere on my file system . ├── cmd │ └── main.go ├── go.mo

Re: [go-nuts] About source folder organization - Part II

some of the more common layouts and trade offs > https://appliedgo.com/blog/go-project-layout > > -eli > > On Mar 21, 2023, at 10:28 AM, Victor Giordano > wrote: > > Hello fellows gophers! > > I do wonder how you organize a project within a file system. Due to the > hi

[go-nuts] About source folder organization - Part II

Hello fellows gophers! I do wonder how you organize a project within a file system. Due to the hierarchical nature of a fs (where is parent folder that constains child folder) I do wonder how do you organize the source files into folders. Can you show me some examples? For example, here

Re: [go-nuts] Re: Will Go be discontinued?

This is first quality human material! Thanks for reviving it!!! El miércoles, 27 de julio de 2022 a las 6:07:17 UTC-3, axel.wa...@googlemail.com escribió: > This thread has been resurrected after 9 years of inactivity. From what I > can tell, there is no reason to do so now. > In particular, th

Re: [go-nuts] fmt.Sscanf strange behaviour

Thanks for the insight again. It is appreciated. Till next time. V El mar, 25 ene 2022 a las 18:05, Ian Lance Taylor () escribió: > On Tue, Jan 25, 2022 at 12:45 PM Victor Giordano > wrote: > > > > Thanks Ian, I will take your advice and use another approach, I regret >

Re: [go-nuts] fmt.Sscanf strange behaviour

022 at 11:35 AM Victor Giordano > wrote: > > > > Hi all! I'm dealing with some multi valued column in postgres, and i > have stomp into a bizzare behavoir in `fmt.Sscanf` > > > > Please take a look at the following snippet, i also leave my question > within the

[go-nuts] fmt.Sscanf strange behaviour

Hi all! I'm dealing with some multi valued column in postgres, and i have stomp into a bizzare behavoir in `fmt.Sscanf` Please take a look at the following snippet, i also leave my question within the code and this link to the playground so you can actually t

[go-nuts] Re: Named types vs not named types

Thanks to all for sharing with me insight. My assessment of the situation until now is: - Changing things indded would be a pain as there is to much build on top of it due to grammar. - If i could back in time i would write this function signature

Re: [go-nuts] Named types vs not named types

. So don't expect me to answer you now, in the short term, I need to re-evaluate my ideas. Thank you for your concern! I really appreciate it a lot. El dom, 27 jun 2021 a las 16:58, 'Axel Wagner' via golang-nuts (< golang-nuts@googlegroups.com>) escribió: > On Sun, Jun 27,

Re: [go-nuts] Named types vs not named types

> and two not named types are different despite having the same definition (like in Pascal) Mmmm.. I really don't know if what I stated is actually true perhaps two not named types with the same definition are the same underlying type. El dom, 27 jun 2021 a las 16:41, Victor

Re: [go-nuts] Named types vs not named types

is kind of > relevant, because you say "typed is better" - but both are typed to the > same degree. > > On Sun, Jun 27, 2021 at 8:55 PM Axel Wagner > wrote: > >> On Sun, Jun 27, 2021 at 8:17 PM Victor Giordano >> wrote: >> >>> But but but... j

Re: [go-nuts] Named types vs not named types

pe I tend to use everywhere it appears. Period. End of the story. I have to admit, although I follow this recipe as a compass, I may pass by sometimes and leave redundant definitions. It is okay, after all, we are humans and errors happen. El dom, 27 jun 2021 a las 13:28, Axel Wagner () escrib

Re: [go-nuts] Named types vs not named types

ake a `http.HandlerFunc`, > because it's purpose is specifically to work on a plain function. If you > have an `http.HandlerFunc`, you can already just call `http.Handle` - there > is no need to make a separate function that takes a *specific* > implementation of `http.Handler`. > >

Re: [go-nuts] Named types vs not named types

er it's a good change or not doesn't exactly matter at > that point. Personally, *if* we could "go back in time" and wouldn't have > to worry about backwards compatibility, my vote would rather be to change > the language to make the HandlerFunc type obsolete > <

[go-nuts] Named types vs not named types

Hello gophers! While studing at this source code in search for some knowledge and enlightment, i do note that in some file a type is defined and then is not used in a place where it could be use

[go-nuts] Re: Count of actually "processed" bytes from csv.Reader

nice! a god old decorator example! thanks El sábado, 31 de octubre de 2020 a las 15:16:12 UTC-3, Severyn Lisovsky escribió: > for everyone interested this is the solution in Go Playground: > https://play.golang.org/p/Rxwcwhai4Gl > > On Saturday, October 31, 2020 at 7:01:08 PM UTC+1 Severyn Lisov

Re: [go-nuts] Untyped nil means literal nil?

t;> associated with an underlying dynamic type >> - dynamically typed nil - a value of interface type with an underlying >> dynamic type that's nil. >> >> Although technically incorrect, I think "untyped nil" is often used to >> refer to the third of thos

[go-nuts] Re: Untyped nil means literal nil?

019, 21:41:59 (UTC-3), Victor Giordano escribió: > > Hello guys, just wanna clarify if the words "Untyped nil" refers to the > nil value placed literally within a expresion, instead of being placed > "behind" a variable, a constanst or a function call return value. So

[go-nuts] Untyped nil means literal nil?

Hello guys, just wanna clarify if the words "Untyped nil" refers to the nil value placed literally within a expresion, instead of being placed "behind" a variable, a constanst or a function call return value. So basically, can i say (in a classroom) that untyped nil means literal nil? Is that co

[go-nuts] Re: What is the reason behind time.Parse using a reference time?

I feel the same way, Jean. I quite don't get it a the first, and still some times i require to look very well to distinguish the layout pattern for the string value beign parsed. El lunes, 14 de abril de 2014, 10:19:29 (UTC-3), Jean de Klerk escribió: > > In java, we do things like new SimpleDa

[go-nuts] Re: functions with arguments vs. function with a receiver?

Hi Joe, to my current understanding of things i would say that both ways are the same and without further context it seems similar. Using a pointer reciever it seems more object-oriented to me, as i have spend many years working in Java. I know this: type S struct {} func (s S) pepe () {} "s

Re: [go-nuts] Channel Feature Suggestion

Those idioms should be documented somewhere! I would use waiting groups for the rest of the job, i don't know.. have to think a little more.. you got the number of background task to wait for, right? El jueves, 21 de febrero de 2019, 10:47:07 (UTC-3), Jan Mercl escribió: > > On Thu, Feb 21, 20

Re: [go-nuts] Re: Documention of a blog entry out of date

tation, please let us know by filing a ticket on > our issue tracker. https://github.com/golang/go/issues > > Peter > > On Monday, February 11, 2019 at 8:19:58 AM UTC-5, Victor Giordano wrote: >> >> Dear all i was reading The defer, panic and recover entry >> <

[go-nuts] Documention of a blog entry out of date

Dear all i was reading The defer, panic and recover entry at the go blog until i found this statement: For a real-world example of panic and recover, see the json package from > the Go standard library. It decodes JSON-encoded data with a set of

Re: [go-nuts] Alternative of defer?

Very nice snippetI Like how you wrap in a clousure the critical section using a lock that comes from the enviorement. I don't know if it is idiomatic but it could be!, and btw this really helps the original "questioner" (using er to honour golang "er" sufix) Thanks for sharing El domingo, 10 de

[go-nuts] Re: Issue using json with array

My bad, if you want to custom your JSON output you should use https://golang.org/pkg/encoding/json/#Marshaler El lunes, 4 de febrero de 2019, 10:56:53 (UTC-3), Victor Giordano escribió: > > Implemeting the Stringer interface could solve your problem > > El martes, 18 de diciembre

[go-nuts] Re: Issue using json with array

Implemeting the Stringer interface could solve your problem El martes, 18 de diciembre de 2018, 22:40:45 (UTC-3), Juan Mamani escribió: > > I'm not an expert but I do my best. > > Original json format required: > { "pos": [{ "lp" : "WISE-12", "lat": "-33,43565400", "lon" : > "-70,60552700",

Re: [go-nuts] Re: why map the key type must not be a function, map, or slice

, at 3:36 PM, Victor Giordano > wrote: > > Probably i need to reveal the underlying problem i was trying to solve > > At a glande: an appoinment subsystem for a health *organization*, > considering practitioners that work on *services *offering *practices *that > refers to *bi

Re: [go-nuts] Re: why map the key type must not be a function, map, or slice

sáb., 26 ene. 2019 a las 16:31, Wagner Riffel () escribió: > i don't quite understand why you're using enums as keys, you can use a > anything but what already was pointed out, following your person example: > https://play.golang.org/p/cuMlPeqR7Qb > > > On Sat, Jan 26, 2

Re: [go-nuts] Re: why map the key type must not be a function, map, or slice

r program example, mainly using the reflection type to > design the mapped key, perhaps the reflected key is a comparable type, but > I mainly propose specific types, such as func, slice, map can not be used > as a key use > > 在 2019年1月25日星期五 UTC+8下午11:31:57，Victor Giordano写道： >>

Re: [go-nuts] Re: why map the key type must not be a function, map, or slice

ice to be a valid key, anything else you can. > > On Fri, Jan 25, 2019 at 12:47 PM Victor Giordano > wrote: > > > > Just wanna say : It would be nice to employ a custom type as a valid key > for a map!!! :D > > > > > > El jueves, 24 de enero de 2019,

Re: [go-nuts] Re: why map the key type must not be a function, map, or slice

Just wanna say : It would be nice to employ a custom type as a valid key for a map!!! :D El jueves, 24 de enero de 2019, 0:47:32 (UTC-3), mount...@gmail.com escribió: > > thanks lan. > > 在 2019年1月23日星期三 UTC+8下午11:26:57，Ian Lance Taylor写道： >> >> On Tue, Jan 22, 2019 at 11:47 PM wrote: >> > >>

Re: [go-nuts] Re: What does "nil implay?

You wrote > All nil values are perfectly defined: they are the zero value of the > particular type. As i see things the nil is the *default value* for the pointers. If you want to call it "zero value" to the default is up to, for me doesn't work like that. For me "zero" (0) is a value and "nil"

Re: [go-nuts] Re: What does "nil implay?

0 != nil El mié., 23 ene. 2019 a las 9:08, Jan Mercl (<0xj...@gmail.com>) escribió: > On Wed, Jan 23, 2019 at 12:45 PM Victor Giordano > wrote: > > >> All nil values are perfectly defined: they are the zero value of the > particular type. > > > > Just t

Re: [go-nuts] Re: What does "nil implay?

El martes, 22 de enero de 2019, 10:23:36 (UTC-3), Jan Mercl escribió: > > On Tue, Jan 22, 2019 at 2:17 PM Victor Giordano > wrote: > > > From a language specific level (higher abstraction) is means undefined, > is the absence of a value. > > No value i

Re: [go-nuts] Re: What does "nil implay?

I was giving an interpretaion about the meaning of nil from different pespectives El martes, 22 de enero de 2019, 10:23:36 (UTC-3), Jan Mercl escribió: > > On Tue, Jan 22, 2019 at 2:17 PM Victor Giordano > wrote: > > > From a language specific level (higher abstraction)

Re: [go-nuts] Using "er" and "able" for interfaces

gt; not bound by English rules. > > Guidelines, not hard rules. io.Reader is not a English word. > > -rob > > > On Fri, Jan 18, 2019 at 6:48 AM Jakob Borg > wrote: > >> On 16 Jan 2019, at 15:42, Victor Giordano > > wrote: >> >> >> As far i can g

Re: [go-nuts] Re: What does "nil implay?

i just make an anwser. El lunes, 21 de enero de 2019, 19:21:29 (UTC-3), Ian Lance Taylor escribió: > > On Mon, Jan 21, 2019 at 5:19 AM 伊藤和也 > > wrote: > > > > So what do you think "nil" represents instead? > > "nil" is just a special value? for slices, maps. > > There is no one answe

[go-nuts] Re: What does "nil implay?

As i see things... - From a language specific level (*higher abstraction*) is means *undefined, is the absence of a value. Something whose value is nil/null/undefined is not defined.* - *On a lower level of abstraction it may be tweeking a little bit for having an application/

Re: [go-nuts] Using "er" and "able" for interfaces

As far i can see from all the previous answers i summarize this. let's see at least if we share some points here: - The *er convention is not better or worse than the *able convention, the former may apply better in some scenarios than the latter. - The "er" suffix goes like a charm with

Re: [go-nuts] Using "er" and "able" for interfaces

nes, not hard rules. io.Reader is not a English word. > > -rob > > > On Fri, Jan 18, 2019 at 6:48 AM Jakob Borg wrote: > >> On 16 Jan 2019, at 15:42, Victor Giordano wrote: >> >> >> As far i can get to understand the english language (i'm not a native >

[go-nuts] Re: what is the use of context in golang RESTful apis?

Hi Mahendra, allow me to point something, as far i can see on this matter, there are two things i would like to address separately: 1) Making a REST API for you application (that can be accessed through http (e.g: an app running in a web server) or, why not?, locally (e.g: an app running that u

Re: [go-nuts] Using "er" and "able" for interfaces

Thanks you both gentleman for sharing your point of view on this! I shall assume that the convention doesn't fit in 100% of the cases. Greetings V El miércoles, 16 de enero de 2019, 12:38:22 (UTC-3), Ian Davis escribió: > > On Wed, 16 Jan 2019, at 2:42 PM, Victor Giordano wrote: >

[go-nuts] Using "er" and "able" for interfaces

Hello all! I don't know very well what is the topic about using "er" or "able" or any other suffix for the single method interfaces (a.k.a. "funcitonal interfaces"), but i would like to address some thoughts, hope you can bear with me, here we go: If a take a look to the Readable interface in Java

Re: [go-nuts] Re: What are the reasonable reasons to use pointers?

and ed over TOPS-10 and TECO (ignoring the brilliantly >>> named SOS, "son of stopgap") >>> >>> On Sun, Jan 6, 2019 at 12:15 PM Rob Pike wrote: >>> >>>> Fortran depends heavily on pointers for its semantics: It is a call by >&g

Re: [go-nuts] Re: What are the reasonable reasons to use pointers?

>> reference language. You just don't see them explicit in the language and >> you have no control over whether an argument will be modified by a >> procedure. >> >> -rob >> >> >> On Mon, Jan 7, 2019 at 5:13 AM Victor Giordano > > wrote: &g

[go-nuts] Re: What are the reasonable reasons to use pointers?

i guess that a good question to start is there is a language that doesn't relays on pointer. Fortran as someone says below, may be a good example how things get done using values only. I programmed in COBOL in the universitiy and don't recall to use pointers. There aren't necessary at all, neve

[go-nuts] new year greetings

To everyone!! Let's say in golang fashion way... func year_2018 () { defer greetingsOf("2019") // code that happened across 2018... } func greetingsOf(year string) { fmt.Println("happy new fresh " + year ) } That is!! Greetings and nice start to all! -- You received this message be

[go-nuts] Re: Best practices for using methods on types to write SQL

Hi Nick!. Allow to me provide you with some insights about working with a sql DBMS as persistence layer for an app. - *Json.Marshal/Unmarshal functions works like a charm* with columns of type JSON. As you state once you have a table with one column of then you can store anything on in

[go-nuts] Re: Defer, clousures and structs

unction to the previously > evaluated bar upon function exit (or after other defers > if there are any). > > Hope that helps > Scott > > On Wednesday, 19 December 2018 23:42:01 UTC+1, Victor Giordano wrote: >> >> Perhaps someone could explain to me (or enlight a lit

[go-nuts] Defer, clousures and structs

Perhaps someone could explain to me (or enlight a litte bit why): why the defer is working like is working in the following cases, so, allow me to go straight to the examples: *https://play.golang.org/p/rLJ48Wur-n0* *My "**rought" **interpretation*: When th

Re: [go-nuts] Declaration of interfaces

, Ian Lance Taylor () escribió: > On Mon, Dec 17, 2018 at 3:08 PM Victor Giordano > wrote: > > > > This is not legal statement right? > > > > > > var a interface{id int} // let's call it "anonymous interface" > > > > > > if we emp

[go-nuts] Declaration of interfaces

This is not legal statement right? var a interface{id int} // let's call it "anonymous interface" if we employ 'interface{}' to refer to empty interfaces it may has sense to think the above declaration as an "anonymous interface" (or inline declared interface). I don't know if it would

Re: [go-nuts] Joke in the air :D

Jajajajjjajajajaj let me commit a big LOL!! El vie., 16 nov. 2018 a las 0:29, Chris FractalBach () escribió: > It reached it's "golden years" > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receivi

Re: [go-nuts] About source folder organization

. 2018 a las 14:37, Victor Giordano () escribió: > 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

Re: [go-nuts] About source folder organization

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 t

Re: [go-nuts] About source folder organization

Thanks for pointing that out. *V* El jue., 15 nov. 2018 a las 12:56, Jan Mercl (<0xj...@gmail.com>) escribió: > On Thu, Nov 15, 2018 at 4:51 PM Victor Giordano > wrote: > > > You may say that i'm a little stubborn but what after i look at others > source files

Re: [go-nuts] About source folder organization

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 gr

Re: [go-nuts] About source folder organization

as 16:40, Jan Mercl (<0xj...@gmail.com>) 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. > .

Re: [go-nuts] About source folder organization

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>) escribió: > It's already removed on SO. > > On Wed, Nov 14, 2018, 20:00 Victor Giordano wrote: > >> hello gopher

[go-nuts] About source folder organization

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

[go-nuts] Re: Calling function with variadic arguments

Very nice investigation. So, this proves that working against interfaces (rather than direct calls) has more burden to the compiler that, in turns, affects the overall program's execution speed? Well, i would guess that someday when duke (from java) meets gopher (from golang) they both will agr

[go-nuts] Joke in the air :D

When an old source file in golang gets old, it gets renamed .gold because it survives time elapsed without being oxidized. -- 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