Optiona, llamar a 1 constructor desde otro constructor

Kravek,

Con respecto a la 1ª pregunta, en C# tendrías que crearte cuatro variantes
de la misma función, la versión general con todos los parámetros y las
especializadas, que se implementan llamando a la versión general:

void f(int a1, int a2, int a3)
{
// programación
}
void f(int a1, int a2)
{
f(a1, a2, 0); // suponiendo que 0 es el valor por defecto para a3
}
void f(int a1)
{
f(a1, 5, 0); // suponiendo que 0 es el valor por defecto para a3 y
5 para a2
}
void f()
{
f(10, 5, 0); // suponiendo que 0 es el valor por defecto para a3, 5
para a2 y 10 para a1
}

Un poco feo, ¿no?

Slds - Octavio

"Kravek" <rubengARROBAkailea4.net> escribió en el mensaje
news:%

Bueno pues tengo 2 dudas:

1ª) Cual es el equivalente del Optional de VB en C#?? Necesito poner 3
parámetros opcionales en un método como se hace?

2º) En un constructor necesito llamar a otro constructor para asignar
diversos valores, ¿cómo se puede hacer eso?¿y si el constructor está en la
clase base en vez de en la clase actual? (en java es con this(...) y con
super(...)

Por eso quería evitar el hacerlo con sobrecarga, con lo bonito que es el VB
y lo automatizado que está y lo poquito automatizado que está el C# teniendo
el mismo entorno de desarrollo...

Kravek, creo que te equivocas. Me parece que mantener los parámetros
opcionales ha sido una pésima decisión de diseño en vb.net. Se que se han
añadido por compatibilidad y que puede ser útil para llamara a código COM,
pero creo que es una mala decisión a largo plazo.

En realidad los diseñadores, tomaron en consideración la posibilidad de
incluir parámetros opcionales en c#, y parece ser que tampoco los incluirán
en Whidbey.

¿Por qué?. Pues por que tiene problemas de ambigüedad. En vb.net no solo hay
que tener en cuenta si existe ya una sobrecarga con la misma signatura. Hay
que tener en cuenta todas las sobrecargas posibles para los parámetros
Optional. Es fácil obtener errores inesperados. En la práctica yo
recomendaría siempre (es lo que hago) jamás utilizar Optional en vb.net y
crear siempre sobrecargas. Tan solo consiste en escribir un poquito más. A
cambio el código es más legible y se eliminan esas dificultades.

Realmente, a parte de que los diseñadores de c#, puedan ser mejores o no,
vb.net tiene mucha carga de compatibilidad, que c# no tiene. C# está
diseñado para .net, que admite sobrecargas. Optional tendría sentido en un
lenguaje que no las admita, o por compatibilidad.

Por otro lado, para mucha gente y por varias razones, un lenguaje será mejor
cuanto más simple se mantenga. Si hay una razón en especial por la que no me
gusta vb.net es por la gran cantidad de elementos innecesarios y redundantes
que mantiene del viejo vb.

Juan Carlos Badiola
MVP - C#

Siempre es un agrado "discutir" contigo ;)

En realidad los diseñadores, tomaron en consideración la posibilidad de
incluir parámetros opcionales en c#, y parece ser que tampoco los

incluirán

en Whidbey.

Que pena!!:(

> ¿Por qué?. Pues por que tiene problemas de ambigüedad. En vb.net no solo

hay

que tener en cuenta si existe ya una sobrecarga con la misma signatura.

Hay

que tener en cuenta todas las sobrecargas posibles para los parámetros
Optional. Es fácil obtener errores inesperados.

A la hora de compilar (sino antes marcandote el IDE un error) se puede mirar
si existe ambigüedad, al igual que si ponemos 2 métodos sobrecargados que
puedan ser ambiguos

<>n la práctica yo

recomendaría siempre (es lo que hago) jamás utilizar Optional en vb.net y
crear siempre sobrecargas. Tan solo consiste en escribir un poquito más. A
cambio el código es más legible y se eliminan esas dificultades.

Lo de Legible no sé yo que decirte... imagina que quiero hacer un método que
me sirva para escribir en pantalla, el código de un 2º programa que use una
libréría quedaría idéntico, ahora bien la libreria que implementa entre
otras cosas dicho código creo que quedaría más clara si tiene algo del tipo:
..., Optional Color colortexto=Color.black, Optional Color
colorfondo=Color.White) ya que el mismo al usar elmétodo te pone cual es el
valor por defecto.

Aún así cuestión de gustos;)

Realmente, a parte de que los diseñadores de c#, puedan ser mejores o no,
vb.net tiene mucha carga de compatibilidad, que c# no tiene. C# está
diseñado para .net, que admite sobrecargas. Optional tendría sentido en un
lenguaje que no las admita, o por compatibilidad.

Totalmente de acuerdo salvo en que los diseñadores de C# seguro que son
muucho mejores que yo, pues se dedican a esto

Por otro lado, para mucha gente y por varias razones, un lenguaje será

mejor

cuanto más simple se mantenga. Si hay una razón en especial por la que no

me

gusta vb.net es por la gran cantidad de elementos innecesarios y

redundantes

que mantiene del viejo vb.

Cuestión de gustos :p, a mi es por una de las razones queme gusta junto a
que su IDE está muy muy automatizado