Questo è il cosiddetto ID campo , un numero intero a 32 bit. Ad eccezione dei dati stessi, questa è l'unica cosa che va oltre il filo per consentire all'altra parte di identificare correttamente il campo a cui appartengono i dati.
In passato il sistema ha fornito automaticamente questi ID internamente, il che ha portato a incompatibilità: se qualcuno ha modificato l'ordine dei campi, ha aggiunto un campo tra altri o campi rimossi. Per motivi di compatibilità, è ancora possibile omettere i numeri e avere il sistema di allocare ID negativi automaticamente 1):
struct yeolde {
i32 foo
string bar
}
ma ora si ottiene una bella avvertimento su di esso:
$ thrift -gen csharp test.thrift
[WARNING:test.thrift:3] No field key specified for foo, resulting protocol may have conflicts or not be backwards compatible!
[WARNING:test.thrift:4] No field key specified for bar, resulting protocol may have conflicts or not be backwards compatible!
Perché salta da 5 a 16?
Uno potrebbe aver deciso che fosse una buona idea. Non ci sono molte restrizioni oltre al fatto che il numero deve essere un valore positivo a 32 bit > 0
.
Oppure ci sono stati campi che sono stati rimossi nel frattempo. Soprattutto per quest'ultimo caso, si consiglia di commentare i campi obsoleti, ma lasciarli nell'IDL per evitare incidenti di compatibilità perché qualcuno "riutilizzava" un vecchio numero di campo già usato e obsoleto per nuovi scopi.
1) Questo è il motivo per cui i numeri ID negativi non sono ammessi.