¿El uso de "net/http" de las variables globales se considera una buena práctica en golang?
(2)
El paquete de golang "net / http" usa la variable global DefaultServeMux para registrar manejadores. ¿Se considera esto una buena práctica o incluso una expresión de golang? ¿Es una variable global después de todo?
Las dos razones principales para no usar variables globales son AFAIK 1) que agregan a la complejidad y 2) son problemáticas en los programas concurrentes.
Quizás 1) no se considera importante en este caso porque el desarrollador puede elegir no usar DefaultServerMux. ¿Qué hay de 2)? ¿Las variables globales son siempre thread / goroutine seguras en Go? Aún así, me sorprende que se use en la biblioteca estándar de Go. Nunca he visto tal práctica en otros idiomas / bibliotecas estándar.
El globvar es, en este caso, tan seguro y tan bueno como el análogo visto en, por ejemplo, el paquete "log".
IOW, la reivindicación 1 es tan vaga como se puede obtener y la reivindicación 2 está restringida: alguna vez / en algún lugar cierto, de lo contrario falso == no se cumple en general aunque se use así.
¿Es una variable global después de todo?
Sí. La variable se define en el nivel raíz, lo que la hace global en todo el paquete.
Sin embargo, esta no es una variable global que almacena toda la información sensible del paquete net/http . Es simplemente una configuración de conveniencia que utiliza el contenido del paquete net/http para proporcionar una oportunidad de inicio rápido para el usuario. Esto también significa que eso no agrega mucha complejidad.
¿Se considera esto una buena práctica o incluso una expresión de golang?
OMI, es una buena práctica ayudar al usuario con el uso de un paquete. Si descubre que puede ahorrarle tiempo al usuario al proporcionar una buena configuración predeterminada, hágalo.
Sin embargo, debe tener cuidado cuando esté a punto de exportar variables. Deben estar listos para el acceso concurrente. El DefaultServeMux (o mejor, el ServeMux subyacente), por ejemplo, está utilizando un mutex para ser seguro para subprocesos.
¿Las variables globales son siempre thread / goroutine seguras en Go?
No. Sin la sincronización adecuada (mutex, channel, ...), todo lo que se accede simultáneamente es problemático y sin dudas soplará todo en pedazos.
Nunca he visto tal práctica en otros idiomas / bibliotecas estándar.
El módulo de logging de Python, por ejemplo, proporciona una función para recuperar el objeto de registro de raíz, sobre el cual se pueden llamar los métodos para personalizar el comportamiento de registro. Esto podría verse como un objeto global, ya que es mutable y se define en el módulo.