Mi carta a los reyes…

Aunque sería para unos reyes que pasaran más allá del 2010, pero bueno… por pedir que no quede 😛

Estas son las cosas que me gustaría que algun dia se incorporasen a C#. Como son fiestas mágicas, pues aquí van para ver si los chicos de Redmond se animan y para algún milenio las tenemos…

Pongo ideas al margen de si son posibles/factibles con el CLR actual… simplemente son cosas que me gustarían que estuviesen en el lenguaje. Solo pongo las ideas y un ejemplo de lo que me gustaría, sin desarrollarlas a fondo… 🙂

1. Conceptos en genéricos

La idea es poder representar como restricción de un tipo genérico algo más allá que una interfaz. Por ejemplo:

concept HasHandle
{
    IntPtr Handle{ get; }        
}

class Foo
{
    public static void Main(string[] args)
    {
        new Foo().Bar(new Form());
    }

    public void Bar<T> (T t)
        where T : HasHandle
        {
            DoWork(t.Handle);
        }
}

Este código deberia compilar porque el concepto HasHandle define una propiedad llamada Handle de tipo IntPtr. El mètode genérico Bar<T> utiliza esta propiedad. Y la llamada a Bar con un paramétro Form satisface el concepto, puesto que la clase Form tiene una propiedad IntPtr llamada Handle.

Los conceptos deberían poder ser genéricos a su vez:

concept HasXXX<T>
{
    T XXX{ get; set;}        
}

class Foo
{
    public void Bar<T,U> (T t)
        where T : HasXXX<U>
        {
            U u = t.XXX;
        }
}

El método Bar<T,U> debería poder llamarse con cualquier tipo T que tuviese una propiedad U XXX {get; set;}

Los conceptos deberían poder hacer referencia a la existencia de métodos estáticos:

concept Comparable<T>
{
    bool operator > (T t1, T t2);
}

class Foo
{
    void Bar<T> (IEnumerable<T> items)
        where T : Comparable<T>
    {
    }
}

El método Bar<T> debería poder llamarse con cualquier tipo T que tuviese definido el operador ‘>’ (aunque este esté definido de forma estática).

2. Constantes binarias

Pues eso mismo…

int i = 0b00001100;

Fácil, no??

3. Tipos anónimos que puedan implementar una interfaz

Los tipos anónimos tal y como estan ahora sirven para poco más que para LINQ. Sería interesante que pudiesen implementar una interfaz y que pudiesen ser devueltos a través de referencias a dicha interfaz:

interface ISomeInterface
{
    int Foo(int);
}

class Bar
{
    ISomeInterface Baz()
    {
        return new ISomeInterface  { void Foo(int i) { return i+1;} };
    }
}

El tipo anónimo creado en el método Baz, implementa la interfaz ISomeInterface y es devuelto a través de una referencia a dicha interfaz.

4. Referencias const

Al estilo de C++. Mira que esto es simple y útil y no se porque no lo han metido… Para más info: http://www.cprogramming.com/tutorial/const_correctness.html.

5. Enumeraciones con cualquier tipo

Estaría bien que los enums pudieran tener cualquier tipo base:

class Planeta
{
    long Diametro { get; set; }
    long DistanciaSol { get; set; }
}
enum SistemaSolar<Planeta>
{
    Mercurio = new Planeta() { Diametro=4879, DistanciaSol=46000000},
    Tierra = new Planeta() { Diametro=12742, DistanciaSol=150000000}
}
class Foo()
{
    Bar () { this.Baz(SistemaSolar.Mercurio);}
    Baz(SistemaSolar p)
    {
        if (p.Diametro > 10000) { ... }
    }
}

El enum SistemaSolar se define como una enumeración de objetos de la clase Planeta.

El método Foo.Baz acepta como parámetro sólo SistemaSolar.Mercurio o SistemaSolar.Tierra. Pasarle cualquier otro objeto Planeta no debería compilar.

Felices fiestaaaaaaaaaaaaaaaaaaaaaaas!

Bueno… paro ya de pedir cosas, jejeeee… 🙂

Solo desearos a todos los geeks unas felices fiestas, llenas de alegría, familia, ceros y unos…

… y que el tió os cague muchos regaloooooooooooooooooooooooooooooooos!!!!

3 comentarios sobre “Mi carta a los reyes…”

  1. Eduard,

    a) La 1 no me gusta – me suena demasiado «dinámica»
    b) 2 y 4 – creo que estoy de acuerdo.
    c) 5 – no me mola. Mercurio y Tierra podrían ser constantes definidas en la propia clase Planeta, con el mismo efecto. Algo similar a lo que se hace por ejemplo en el tipo System.Drawing.Color de .NET.
    d) La 3 – me parece muy necesaria. Me gustaría saber tu opinión sobre estas sugerencias que he puesto en connect:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=390138

    y

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=390141

    Son variantes enriquecidas con tu idea de esta otra que puse hace casi un año sin que le hicieran mucho caso:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=317192

    Slds – Octavio

  2. Hola Octavio. Muchas gracias por tu comentario 😉

    He echado un vistazo a lo que propones en https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=390141

    Aunque el hecho de que un tipo anónimo implemente IDataRecord hace que pueda devolverse entre métodos, el acceso a sus propiedades es muy dinámico, no???
    No se si he entendido lo que propones: lo que me ha parecido a mi es que todos los tipos anónimos implementen IDataRecord (cosa que haria el compilador).
    Así si tengo mi tipo anónimo

    new { Name = «Suprunaman» Serie=»Dr Slump» }

    podria acceder a sus propiedades mediante [«Name»] y [«Serie»] a través de la interfaz IDataRecord (y seria al compilador quien usara reflection por debajo).
    Pero… que diferencia tendria esto con devolver object desde la función que tiene el tipo anónimo y usar dynamic? En ambos casos la llamada se resuelve en tiempo de ejecución… no se, por eso no se si he terminado de entender tu sugerencia 🙂

    Sobre la segunda sugerencia (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=390141)
    estoy totalmente de acuerdo 🙂

    Sobre el resto de tus comentarios, respondo muy brevemente (que si no me embalo y no paro xDDD)

    a) No veo que la 1 sea tan dinámica, entendiendo que todas las comprobaciones las realizaria el compilador. Que una clase «satisfaga» un concepto viene a ser como que «implemente» una interfaz, salvo que nada de esto se trasladaría en run-time. Admito el hecho de que para que se quede en tiempo de compilación el chequeo de si un objeto satisface un concepto debería hacerse en base al tipo de la referencia. Es una idea que he sacado de las especificaciones de C++0x, donde hay algo parecido (aunque mucho más complejo, como no) 😛

    c) La única diferencia en tener Mercurio y Tierra en un enum respecto a tenerlos como constantes en la propia clase Planeta es que, con el segundo método, no puedes evitar que sólo te lleguen Mercurio o Tierra: tu método funcionará con cualquier Planeta. Para ser honestos, si «existieran» esos enums tipados deberían ser de clases que no se pudieran modificar… o mejor aún, deberian devolver referencias const si las tuvieramos 😛 Esta idea tampoco es original mía, claro… java tiene algo parecido a esto.

    Saludos y feliz año!

Responder a ohernandez Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *