Cosa ne pensi di questa nuova sintassi if-then [chiuso]

Stavo solo pensando a qualcosa che sarebbe davvero bello avere nei miei controlli if-elif-else.

if condition:
    stuff()
elif condition:
    otherstuff()
then:
    stuff_that_applies_to_both()
else:
    stuff_that_doesnt_aply_to_either()

Quindi sostanzialmente thenverrà eseguito quando viene eseguita una delle condizioni TRANNE la condizione else. Pensi che sia utile? È simile al try-tranne-else di Python.

Penso che alcuni di voi stiano cogliando un'implementazione molto preliminare. Il thenblocco sarebbe proprio come il elseblocco in un try-exceptblocco in Python. Il vero motivo per cui suggerisco questo è per situazioni come questa.

m = {}
if condition == '1':
    m['condition'] = condition
elif condition2 == '3':
    m['condition2'] = condition2
elif condition3 == 'False':
    m['condition3'] = True
then:
    run_test_that_relies_on_one_of_the_conditions_being_true()

return m

Il thenblocco è impostato sul primo se proprio come elseè. Quindi la nidificazione funziona bene. E se è necessario eseguire un metodo prima delle istruzioni if, ciò non ha nulla a che fare con questo caso d'uso.

Penso che sia orribile. Se si desidera che il codice venga eseguito dopo una varietà di condizioni, (a) ricontrollare tali condizioni o (b) impostare una variabile sullo stato di successo indicato.

Generalmente puoi già farlo con un interruttore / caso e un interruttore / caso fornisce un controllo più preciso su ciò che stai proponendo.

Inoltre non legge correttamente logicamente. Se A altro se B, allora C. Non implica per qualcuno che C verrà eseguito se A o B vengono valutati come veri.

Interessante, ma mi sembra (certamente in qualche modo impostato nei miei modi) un invito a problemi di leggibilità, logica e sintassi.

Modifica: Il tuo if-elif è molto semplice - e se ci fossero 10 elif? 20? Tutte le condizioni dovrebbero essere vere? Quali sono le possibilità?
Il tuo if-elif è molto semplice - e se ci fossero 10 elif? 20? Ciò non lo renderebbe abbastanza illeggibile?

Inoltre, può essere facilmente raggiunto con una metodologia consolidata e comprovata:

if (thisCondition or thatCondition)
{
  if (thisCondition)
     stuff();
  else
     otherstuff();

    stuff_that_applies_to_both();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Cosa succede se "stuff_that_applies_to_both" deve avvenire prima dei singoli passaggi? Il tuo codice non gestisce questo caso:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

  if (thisCondition)
     stuff();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Infine, questa sintassi consente una maggiore flessibilità con più condizioni: if (thisCondition o thatCondition o anotherCondition) {stuff_that_applies_to_all ();

  // Any combination of the three conditions using 
  // whichever logical syntax you'd like here
  if (thisCondition and anotherCondition)
     stuff();
  else if (thisCondition or thatCondition)
     stuff_number_2();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Ho usato if / else, ma avrei potuto usare altrettanto facilmente un'istruzione switch con un flag:

Boolean conditionApplies = true;

switch (someConditionToCheck)
{
    case thisCondition:
      stuff();
      break;

    case thatCondition:
        otherStuff();
        break;

    default:
        stuff_that_doesnt_aply_sic_to_either();
        conditionApplies = false;
        break;
}

if (conditionApplies)
    stuff_that_applies_to_both();

Nota che in realtà non avevo bisogno del flag conditionApplies - avrei potuto aggiungere la funzione "stuff_that_applies_to_both ()" a entrambe le condizioni non predefinite - l'ho appena fatto in modo che assomigli di più alla sintassi definita sopra, anche se "allora" piuttosto che "altro".

Pertanto, mi sembra una sintassi molto specializzata, in cui una sintassi più generale riempie il conto e altro ancora.

+1 per pensare a una possibile funzionalità (continua a farlo!), Ma non voterei per implementarla.

Oggi non mi dispiacerebbe usare qualcosa del genere. Ma, per essere sicuro, lo userei tutte le volte che uso ripetizione fino a.

Il codice avrebbe almeno un aspetto migliore senza l'annidamento superfluo. Anche se io preferisco Else Ifa elif. Sostituirei Thencon Doe il finale Elsecon Otherwise.

Sembra una bella idea. Tuttavia, l'unico problema che immagino è che sei più soggetto agli errori. Come scrivere un if / else if e chiamare blah () in allora. Scrivendo un altro se questo non vuole blah, rimuovendo blah da allora e aggiungendolo ai tuoi ifs / elseifs. Quindi quando tu o un altro programmatore aggiungete un'altra affermazione, potreste aspettarvi che blah venga chiamato ma non.

Oppure puoi avere diversi if, scrivere un blah e dimenticare tutti gli if ma uno richiede questo che romperebbe qualcosa. Inoltre, se hai bisogno di seguirli ogni volta, li metterai sotto il blocco if. Possibilmente impostare un valore bool in else (NoUpdate = true) e scrivere un if (! NoUpdate) {} direttamente sotto il quale è più chiaro e può essere impostato da un if

Sto solo dicendo che sembra più incline ai bug, non che l'idea non mi piaccia. Non mi dispiacerebbe vederlo in una lingua ma non riesco a immaginare alcuna situtaion in cui la userei se la mia lingua lo supporta.

Trovo la tua sintassi confusa, ma vedo un certo valore nel concetto. Concettualmente, quando ho preso in considerazione il problema, quello che mi sono ritrovato a desiderare è un "unelse", che sostanzialmente avrebbe eseguito le cose nei casi in cui l'ultimo elsenon ha sparato. Osservandolo da quell'angolazione, suggerirei che si potesse ottenere un risultato simile tramite:

  fare
  {
    if (condizione1)
      ... roba solo per condition1
    else if (condizione2)
      ... roba solo per condition2
    altro
    {
      ... roba per nessuna delle due condizioni
      rompere;
    }
    ... roba per entrambe le condizioni
  } while (0); // Punto di continuazione per l'interruzione

Un'altra opzione può essere in alcuni casi:

  if ((condition1 && (action1,1)) ||
       (condizione2 && (azione2,1)) ||
       (Action_for_neither, 0))
    action_for_either;

Un aspetto un po 'brutto, ma in alcuni casi potrebbe non esserci un buon modo per esprimere la sequenza desiderata di eventi oltre a duplicare il codice o usare goto(che potrebbe non essere così male, tranne per il cartone animato che qualcuno potrebbe inserire qui).