VB.NET Late Binding

di Cristian Civera, in .NET,

Vorrei appoggiare la causa di Andrea. In questo post parla delle differenze tra C# e VB.NET. Trovo assurdo che uno sviluppatore possa aver scelto un linguaggio al posto di un altro perché è più comodo e semplice a discapito delle prestazioni.

Per chi non ci crede, fate una pagina aspx così:

sub Page_Load(s as object, e as EventArgs)
Response.Write(s.Request)
end sub

Queste tre righe funzionano perfettamente. "s" è di tipo object ma sfruttando il late binding possiamo accedere alla proprietà Request della classe Page.
Se guardiamo il codice compilato vedremo che vbc ha prodotto del codice in più:

Sub Page_Load(s As Object, e As EventArgs)
Response.Write(RuntimeHelpers.GetObjectValue(LateBinding.LateGet(s, Nothing, "Request", New Object(0) {}, Nothing, Nothing)))
End Sub

In pratica, utilizza la funzione LateBinding.LateGet (Microsoft.VisualBasic.CompilerServices) per prelevare il valore. Lo fa passando il riferimento all'oggetto s, nothing che sarebbe il tipo ma è sconosciuto, "Request" come nome del membro, un array di oggetto come parametri (utilizzato per proprietà indicizzate), i nomi dei parametri e se devono essere copiati (nothing perché non ci sono). Una volta prelevato il valore utilizza GetObjectValue per effettuare il boxing nel caso sia un tipo di valore, come interi ecc.
Il metodo LateGet lavora via reflection per cercare il membro richiesto e prelevarne il valore. Tutto questo lavoro comporta un notevole spreco di tempo e degrado delle performance. Non ho avuto tempo di fare test per darvi dei numeri ma a me questo fa già passare la voglia di tenere disabilitato l'option strict.

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Nella stessa categoria
I più letti del mese