5 funcions útils que no veureu al llenguatge de programació Go

Després de més de 12 anys a la natura, el llenguatge Go s’ha consolidat com una eina per a programadors professionals i per construir sistemes a gran escala. Tot i que Go és deliberadament reservat, net i eficient, les sol·licituds de determinades funcions apareixen una vegada i una altra, fins i tot si en una inspecció més propera aquestes funcions van en contra de les filosofies o objectius de disseny subjacents de Go.

Aquí hi ha cinc funcions més sol·licitades a Go, totes les quals és probable que no les vegeu o que només es mostraran en una forma que complementi la resta del que hi ha a Go ara.

Operador ternari

Moltes llengües tenen una construcció que és essencialment un if/then/else bloquejar en una sola declaració. Per exemple, a Python podem escriure, x = 1 if condition else 0o en JavaScript podem escriure, x = condition ? 1 : 0.

Les PMF de Go són bastant contundents sobre per què l’idioma no té aquesta funció:

Els dissenyadors del llenguatge havien vist que l’operació s’utilitzava massa sovint per crear expressions impenetrablement complexes… Un llenguatge només necessita un constructe de flux de control condicional.

Molts programadors de Go estan d’acord amb aquesta avaluació, a jutjar pels comentaris d’una proposta per a un operador ternari el 2019. Les propostes relacionades, com ara una d’assignació condicional a principis d’aquest any, tampoc no van guanyar força.

Tipus de suma o tipus algebraics

Una altra característica que es troba en idiomes moderns com Rust és el tipus de suma. També conegut com a tipus algebraic o tipus variant, un tipus de suma és una variable que pot ser qualsevol dels diversos tipus possibles no anul·lables. En alguns idiomes, un tipus de suma es pot utilitzar com a manera de retornar un valor vàlid o un valor d’error d’una operació.

A alguns programadors de Go els agrada la idea de tenir aquests tipus. En teoria, un tipus no anul·lable facilitaria la gestió de comprovacions nil. Els tipus de suma també farien que la gestió d’errors sigui més elegant.

Tanmateix, les propostes per a aquestes millores del sistema no s’han retirat. Aneu interface El tipus s’ha convertit en la manera idiomàtica d’implementar molts dels mateixos mecanismes que els manejarien els tipus de suma.

Les PMF de Go diuen això sobre el problema:

Vam considerar afegir tipus de variants a Go, però després de la discussió vam decidir deixar-los fora perquè es superposen de manera confusa amb les interfícies. Què passaria si els elements d’un tipus de variant fossin ells mateixos interfícies?

Una proposta de 2017 per a tipus de suma, ara rebutjada, apuntava a una discussió del co-creador del llenguatge Go, Russ Cox, en què Cox va plantejar les mateixes preocupacions sobre les interfícies.

Tipus d’estructura immutables

Molts idiomes donen suport a la idea d’una estructura immutable, no només una variable escalar que serveix com a constant (com un nombre enter o un flotant), sinó una col·lecció d’elements d’ordre superior que és immutable.

Go permet al programador crear constants, però només per a tipus escalars, com ara nombres enters o flotants. A Go no és possible crear una porció immutable d’enters, per exemple. L’única manera de tenir alguna cosa com comportaments immutables a Go és fer còpies de coses i operar-hi. Això pot ser lent i suposa una càrrega addicional per al desenvolupador per assegurar-se que de fet copien i no operen amb originals.

Han aparegut propostes per crear tipus immutables a Go 1.x. Un dels més complets va proposar donar a cada tipus una contrapartida immutable i va oferir suggeriments per implementar mètodes d’interfície immutable. Les objeccions a la proposta van plantejar “defectes importants” com ara const l’enverinament, per la qual cosa afegir comportaments constants en una part d’un programa requeria que tots els camins de codi dependents també els implementessin, o després esdevinguessin difícils de desfer. Un usuari de llarga data del llenguatge D va descriure la seva experiència amb una característica similar afegida a aquest llenguatge i com complicava les coses de manera imprevisible.

Valors d’argument per defecte

Una altra característica que trobareu en molts altres llenguatges de programació són els valors d’argument predeterminats per a mètodes o funcions. Aquí un mètode s’inicialitza amb valors predeterminats, de manera que si no proporcioneu arguments quan el truqueu, el mètode proporcionarà els valors predeterminats.

Go no té cap característica com aquesta, ja que els seus dissenyadors van considerar que va en contra de la filosofia del llenguatge. Una objecció és que els valors d’argument predeterminats fomenten un disseny deficient de l’API, perquè permeten canviar els arguments d’una funció després d’haver-se establert. Les propostes per afegir aquesta funció a l’idioma tan recentment com el 2020 s’han rebutjat pels mateixos motius.

Un substitut potencial dels valors d’argument predeterminats són les funcions variàdiques, que són funcions que poden prendre qualsevol nombre del mateix tipus d’arguments. Les funcions variàdiques permetrien passar més arguments a la funció més endavant i que els arguments no proporcionats se’ls assignin valors automàticament. Però tot això té el preu de no ser descrit explícitament a la signatura de la funció, cosa que va en contra de la filosofia de Go.

Tractament d’errors convencional

La gestió d’errors a Go funciona perquè les funcions retornin tant un valor normal com un valor d’error. Si el valor d’error és qualsevol cosa menys nils’ha produït un error i correspon a la persona que truca gestionar-lo.

És un enfocament senzill però també repetitiu i detallat, de vegades excessivament. Aneu panic/recover El patró, el més semblant que té el llenguatge a les excepcions, no s’ha d’utilitzar per a la comprovació regular d’errors, sinó per rescatar un programa que s’estavella.

Un objectiu obert per a una versió futura de Go és una millor manera de gestionar els errors, però fins ara s’ha produït poc que sembla probable que substitueixi el comú. if err != nil placa de la caldera.

Una proposta era substituir el patró comú (és a dir, executar una funció, obtenir els seus valors juntament amb un error i retornar l’error a la cadena de trucades si no ésnil) amb una funció de verificació d’errors integrada anomenada try. Però molts usuaris de Go es van resistir a la idea per moltes raons, inclosa la raó per la qual una construcció més concisa no és una solució al problema, de manera que el try la proposta va ser rebutjada.

Qualsevol canvi en la manera com Go gestiona els errors primer haurà de satisfer els seus usuaris existents, molts dels quals veuen la verbositat i l’explicitat de Go com un benefici i no una càrrega.

Copyright © 2022 IDG Communications, Inc.

Leave a Comment

Your email address will not be published. Required fields are marked *