First, let me apologize for writing in a way that you took to be aggressive. That was definitely not my intention. My state of mind when I wrote it was conversational, not antagonistic, and I did not realize you would interpret it any other way.
* gera...@cloudoki.com <gera...@cloudoki.com> [191018 11:08]: > hey, Marvin, > > Actually I haven't noticed it was a 8 year old thread, neither had I > noticed that there should be any kind of preface in such cases (well, it > was just a comment and the group rules are not that clear, afterall). There is no such formal rule in this group. However, if you consider how a mailing list or online discussion group works, you have many (in this case presumably thousands of) readers who are reading the posts chronologically as they are posted. They have, typically, shorter memory for details and longer memory for general trends. When you post a reply to a thread that died years ago, it is helpful to give these thousands of readers a clue that they will have to go back to the archives to figure out what the thread was about. My intent was to be instructional, not critical. Again, if you felt I was criticizing you, please accept my apologies. > My > comment was about a rather *usual feature in OOP languages and that people > with experience in such languages might wonder what's the idiomatic was to > express the same concept in GO*, that's why the comment was made with this > a caveat about its idiomaticity. Fair enough. On the other hand, Go is not intended to be an OO language. When people new to Go post on this list with OO preconceptions about writing code in Go, they are frequently given the suggestion to rethink the structure of their program using Go concepts, rather than trying to shoe-horn the Go language to OO concepts. > About *the subject*: I agree with you that the convention T/NewT is > sufficient, but in some contexts (like packages with many structs and many > functions that should me modelled as static methods in other languages) it > might clog the package namespace. That might lead programmers unexperienced > to GO into modelling *packages-as-classes*, which, I might be wrong, but I > believe it is not intention designed for them. If I understand correctly what you are saying, I think you are right that trying to use Go packages as OO classes will generally lead to less robust and less idiomatic Go code. I'm not sure I understand which side you are on about NewT vs. T.New, but even in large packages with many types, I don't think that using NewT will clog the namespace any more than T.New will. > About *your message*: I believe that most people might disagree with static > methods in GO (*maybe me included*), some might not, but anyways I believe > you're not entitled to speak in the name of everyone on this group, are > you? I was not trying to speak for them. I specifically said I "suspect" (my opinion based on experience) "many" (not all) will disagree. This opinion was based on what has been written by others on this list over the many years that I have read and participated in discussions here. > And, moreover, I do not think the aggressive tone on your message is > consistent with a *discussion* group. Again, I apologize if I sounded aggressive. In a written medium, it is difficult to convey tone. If you were to take a heated verbal technical discussion between two close colleagues and transcribe it, a third party reading it my very well get the impression that the two were bitter enemies. ...Marvin -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191018183019.epivtdb6w4ggauly%40basil.wdw.
