Qual è il caso d'uso per le variabili di shadowing?

Question

Qual è il caso d'uso per le variabili di shadowing?

#1 da (6 voti)
#2 da (1 voti)

1

Una delle cose per cui il linguaggio di programmazione del coffeescript è criticato è il suo trattamento delle dichiarazioni variabili e dello scope ( esempio ).

Le risposte a questo domanda (e il blog che ho collegato sopra) sembrano incentrarsi sulla falsa dicotomia delle variabili che possono essere oscurate o essere globali. In qualsiasi linguaggio con regole di scoping ragionevoli, questa presunzione sembra (per me) essere un non-sequencer. Nel summenzionato coffeescript:

foo = 5
f = () ->
  foo = 12 #foo in the outer scope is closed-over
  bar = 3  #binds a name in f's scope
  null

f()
foo #12
bar #undefined because it was bound in an inner scope

Quindi chiaramente, la barra non è globale. Se lo snippet qui sopra fosse esso stesso all'interno di un ambito non globale, allora foo non lo sarebbe nemmeno. Mi sembra che ombreggiare una variabile da un ambito esterno in una lingua con chiusura lessicale potrebbe solo creare confusione. Quindi, perché il coffeescript viene sbattuto per rimuovere la possibilità? C'è un caso d'uso importante qui mi manca? Indipendentemente da come ci si può sentire riguardo al resto del coffeescript, questo comportamento mi sembra desiderabile.

variables scope closures coffeescript

posta Jared Smith 07.01.2016 - 19:46

fonte

2 risposte

1

Il backlash verso CoffeeScript in particolare è probabile perché CoffeeScript dovrebbe essere un linguaggio simile a Javascript; è pubblicizzato come variazione o estensione di Javascript. La home page dice anche:

The golden rule of CoffeeScript is: "It's just JavaScript".

Gli sviluppatori di Javascript potrebbero essere riluttanti a provare CoffeeScript quando il comportamento implicito fondamentale a cui sono abituati è stato modificato.

risposta data 07.01.2016 - 23:10

fonte

Leggi altre domande sui tag variables scope closures coffeescript

Come vengono memorizzate singole righe di codice e funzioni in un Concrete Syntax Tree? Progettazione di database multi-tenant

score 6 · Accepted Answer

Il problema con il modo in cui lo descrivi (non conosco coffeescript) è che rende troppo facile rompere il codice esistente senza rendersene conto. Supponiamo che tu abbia questo codice:

bar = 5
// 100 lines of code
f = () ->
    foo = 12
    null

// 100 lines of code
print bar

Ora decidi che "bar" è un nome schifoso e rinominerai il globale in "foo". All'improvviso si scatena l'inferno. Forse non te ne accorgi nemmeno subito, scivola tra i tuoi test e colpisce la produzione.

Ora considera altre strategie:

Ombre (C / C ++ / altri) Hanno ombre globali locali. In questo caso, il codice viene eseguito come è. foo nello scope locale non influenza l'ambito globale, quindi tutto funziona come prima.

Disallow (C #) Il compilatore ti dice di non farlo. Puoi cambiare il nome di uno o dell'altro e tutto va bene.

Ombra o rende esplicito (Python) Dispone di globals ombra locali, ma lascia che gli sviluppatori facciano esplicitamente uso del globale. Di nuovo, tutto funziona come prima.

Un caso d'uso correlato, per il quale si applicano questi stessi commenti, è se si estrae la funzione esistente, semplicemente copiando il codice o utilizzando un metodo di inclusione, dove un locale capita di utilizzare il nome di un globale nel nuovo file.