No it can have its uses.
It really depends on what you are doing. However, I've never done this as a
way to declare some kind of namespace.
Typically, I use that in testing when I want a dummy type to implement an
interface.
That's just an example.
It can be used also if you export the struct
Personally I do that (despite that everyone advocates against it). Just
remember your struct should be just "struct{}" and nothing else. This
helped me to use shorter & cleaner names for my functions - actually it
converts a function pile to a batch of functions).
On Wednesday, August 3, 2016 a
Are there any advantages over using real packages?
--
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, vis
Hi,
For starters, packages can't implement interfaces.
Cheers,
On Friday, August 5, 2016 at 6:19:31 AM UTC+2, Christoph Berger wrote:
>
> Are there any advantages over using real packages?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To uns
You just declared a global variable. the standard library does exactly that
with http Client. I assume if it is in the std lib I don't see why you
shouldn't do that yourself.
Le mercredi 3 août 2016 15:19:52 UTC+2, d a écrit :
>
> Hi all, just saw a piece of software that make large use of metho
Hi Christian,
You’re right on this, but my question is about another aspect. The thread
starter’s question was about using structs for namespaces (instead of
packages). My question is, why would someone want to use empty structs for
creating a name space if a package already does this. After al
