C # / VB.NET costruiscono alberi di espressioni solo da espressioni lambda - perché?

Question

C # / VB.NET costruiscono alberi di espressioni solo da espressioni lambda - perché?

#1 da (3 voti)
#2 da (1 voti)

3

In base al contesto, C # può generare l'albero dell'espressione per un LambdaExpression dalla sintassi delle espressioni lambda:

Expression<Func<string, int>> expr1 = s => s.Length;

come può VB.NET:

Dim expr1 As Expression(Of Func(Of String,Integer)) = Function(s) s.Length

Perché il compilatore di una lingua non può generare una struttura di espressioni da altri tipi di espressioni?

C #:

Expression<DateTime> expr2 = DateTime.Now

VB.NET:

Dim expr2 As Expression(Of DateTime) = DateTime.Now

Sto assumendo che questo comportamento sia dovuto alla progettazione; o ci sono ragioni tecniche che lo rendono impraticabile; oppure non è necessario per i requisiti che hanno reso necessario il Expressions in primo luogo - query LINQ. Vorrei ulteriori dettagli sull'argomento.

language-design .net

posta Zev Spitz 16.01.2016 - 20:26

fonte

2 risposte

1

Sappiamo già che il meccanismo di generazione dell'albero delle espressioni è in grado di generare un albero di espressioni per qualsiasi espressione arbitraria, poiché è in grado di generare un albero di espressioni per qualsiasi espressione arbitraria all'interno di una lambda. Quindi è chiaro che i limiti tecnici non sono il problema. La risposta più probabile è che è stata utilizzata solo per le trasformazioni automatiche di lambda negli alberi di espressione perché era l'unica cosa per cui LINQ aveva bisogno e gli alberi di espressione sono stati creati per LINQ.

risposta data 16.01.2016 - 21:32

fonte

Leggi altre domande sui tag language-design .net

È una cattiva idea mettere la logica dipendente esternamente nelle classi ORM? Cancella i dati utente quando si disconnettono?

score 3 · Accepted Answer

Secondo me, il motivo principale per cui questa funzione non è disponibile a causa del fatto che i progettisti linguistici non sono tenuti a implementarlo o non vedono il punto nel farlo, poiché questo può essere già ottenuto con lambda in modo sano.

Probabilmente la funzione è probabilmente tecnicamente possibile, dal momento che tutte le espressioni possono essere scritte come lambdas
L'adozione significherebbe che ciascuna espressione può generare albero di espressioni o essere valutata
- Può portare a una diminuzione della leggibilità del codice a causa della grande differenza semantica tra T e Expression<T> in confronto con Func<T> e Expression<Func<T>>
- L'ambiguità esiste già per lambda
  - Risolto automaticamente in VB.NET in modo predefinito per delegare
  - Non risolto automaticamente in C #, presumibilmente i progettisti volevano che i programmatori disambigessero tra le opzioni stesse
    - Pertanto, questa funzionalità andrebbe contro le precedenti decisioni di progettazione, sia per impostazione predefinita a un delegato o rimuovendo i tipi anonimi.