c# - uipath - tryparse java

¿Por qué T.TryParse no devuelve un Nullable<T>

Question

Por lo que sé, int.TryParse(string, out int) existe desde Framework 2.0. Entonces, ¿lo hace int? .

¿Hay alguna razón para usar un parámetro de out lugar de devolver un int? con HasValue establecido en true false según la capacidad de conversión?

Answer 1

Aquí hay una cita del blog de Julie Lerman (A partir de 2004):

He jugado con nullable en los bits de previsualización de marzo, pero aún no en mayo y decepcionado con el rendimiento actual (pero programado para una mejora seria por parte del equipo bcl!) Cuando comparé el uso de nullable<t> sobre las opciones actuales. Así, por ejemplo, con tipos de valor:

comparar myNullableInt.HasValue a (en VB) es myInt < 0

o con tipos de referencia

comparando myNullableThing.HasValue a " if not myThing=null "

el tipo anulable es actualmente mucho más lento . Unos pocos miembros del equipo de BCL me han prometido que el plan es hacer que el MUCHO sea más eficaz .

También me han dado la pista de que en el futuro será posible lo siguiente:

Nullable<T> Parse(string value);
Nullable<Int32> i = Int32.Parse( some String );

Y será más performante que TryParse . Así que, también será interesante.

Supongo que, como siempre, el beneficio supera el costo.

De todos modos, en el próximo C # vNext, puedes hacer:

DateTime.TryParse(s, out var parsedDateTime);

Convirtiendo TryParse en un trazador de líneas.

Answer 2

En cuanto a razones solo podemos adivinar, pero algunas posibles razones son:

Sobrecarga de asignación: un valor en caja incurre en una sobrecarga de rendimiento (pequeña) sobre un tipo incorporado.

No hay ganancias reales:

int res;
if int.TryParse("one", out res) {
//something
}

no es mucho peor que

int? res = int.TryParse("one");
if (res.HasValue){
int realres = res.Value
//something
}

Answer 3

La razón simple es que cuando se agregó int.TryParse al idioma, Nullable<T> no existía.

En esta publicación del blog de Eric Lippert , hay una línea hacia abajo que dice:

La solución es escribir su propia versión del método de extensión de TryParse de la forma en que se habría escrito si hubieran existido tipos de valores anulables disponibles en primer lugar

lo que deja en claro que los tipos anulables no estaban disponibles para ser utilizados en la implementación original de TryParse . Eric Lippert estaba en el equipo que escribió el compilador de C #, así que diría que es una fuente bastante autorizada.

Answer 4

No puedo decir acerca de las razones reales, pero veo tres razones posibles:

1) Los tipos anulables se introdujeron en .NET 2.0, mientras que los primeros métodos TryParse ya existían desde .NET 1.1. Por lo tanto, cuando se introdujeron tipos anulables, era demasiado tarde para tal cambio de API; y las nuevas clases no implementarían TryParse diferente porque el patrón ya se había establecido.

2) No todos los tipos se pueden usar con la estructura de Nullable , solo los tipos de valor pueden. Sin embargo, hay métodos que siguen el patrón Try* que tienen que devolver tipos de referencia. Por ejemplo, un diccionario puede contener totalmente null legítimamente como un elemento, por lo tanto, su método TryGetValue necesita una forma adicional de expresar que no se encontró una clave.

3) La forma en que se escriben los métodos Try* , es posible escribir código como este:

int myValue;
if (int.TryParse("42", out myValue)) {
// do something with myValue
}
// do something else
}

Ahora, imagina si TryParse solo devuelve un int? . Puede eliminar la variable myValue y perder el resultado:

if (int.TryParse("42").HasValue) {
// do something with ... what? You didn''t store the conversion result!
}
// do something else
}

O puede agregar una variable anulable:

int? myValue = int.TryParse("42");
if (myValue.HasValue) {
// do something with myValue.Value
}
// do something else
}

Esto ya no es una ventaja sobre la versión actual, y en su lugar requiere la escritura de myValue.Value en algunas instancias posteriores, donde de lo contrario hubiera bastado con un value simple. Tenga en cuenta que en muchos casos, solo necesita la información sobre si la operación fue exitosa para la sentencia if .

Answer 5

Otra posible razón:

Los genéricos para .NET y C # en su forma actual casi no sucedieron: fue una decisión muy cercana, y la característica casi no logró el corte para Whidbey (Visual Studio 2005). Las características tales como ejecutar el código CLR en la base de datos recibieron mayor prioridad.

...

En última instancia, se habría adoptado un modelo de borrado de genéricos, como para Java, ya que el equipo de CLR nunca habría seguido un diseño de genéricos en la máquina virtual sin ayuda externa.

fuente: http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-generics-history-some-photos-from-feb-1999.aspx

Mi punto es: la mayoría de los cambios en el BCL (o al menos los que no están directamente relacionados con los genéricos) probablemente debían funcionar con y sin genéricos , en caso de que esa característica se eliminara en el RTM final.

Por supuesto, esto también tiene sentido desde la perspectiva del cliente que llama: todos los lenguajes que consumen (bueno, no había tantos en ese entonces) idealmente podrían usarlos, y out parámetros no eran tan genéricos como los genéricos. .