Ornitorrinco

No todo lo que camina como un pato, nada como un pato y pone huevos como un pato, tiene necesariamente que ser un pato. Podría tratarse de un ornitorrinco, ¿verdad?

Suponga que yo le digo que esto es Freya:

IStack = interface[X]
    Count: Integer;
    Top: X;
    method Push(Value: X);
    method Pop;
        requires Count > 0;

    IsEmpty: Boolean => Count = 0;
end;

Para que le resulte más fácil detectar el elemento extraño, utilizaré una sintaxis equivalente, algo más verbosa:

IStack = interface[X]
    property Count: Integer;
    property Top: X;
    method Push(Value: X);
    method Pop;
        requires Count > 0;

    property IsEmpty: Boolean;
    begin
        Result := Count = 0;
    end;
end;

Y ahora, antes de subir la otra mitad del artículo, dígame si lo anterior le parece bien o mal...

---

Efectivamente, como mencionaba Marto en un comentario, se supone que las interfaces no "implementan". Sin embargo, es precisamente ese efecto lo que logran los métodos de extensión de C^# 3.0:

interface IStack<X>
{
    int Count { get; }
    X Top { get; }
    void Push(X value);
    void Pop();
}

static class StackExt
{
    public static bool IsEmpty<X>(this IStack<X> s)
    {
        return s.Count == 0;
    }
}

Gracias a estos métodos, es posible escribir código como el siguiente, suponiendo que tenemos ya una clase que implementa el tipo de interfaz:

IStack<int> st = new StackImpl<int>();
if (st.IsEmpty()) { ... }

¿Es bueno, o es malo? No veo nada malo en permitir manipulaciones predefinidas sobre el estado "público" ofrecido por el contrato de la interfaz: lo mismo se puede lograr, incluso sin métodos de extensión, aunque al precio de escribir muchísimo más.

Ahora bien, mi duda va más allá. ¿Merece la pena implementar métodos de extensión (Freya ya los tiene), o sería suficiente con añadir al lenguaje implementaciones predefinidas en interfaces, como la del ejemplo de Freya? El caso es que los métodos de extensión son nada elegantes:

• El mecanismo de selección es horrible: basta con introducir una cláusula using para activarlos, dándole un protagonismo inapropiado a estas cláusulas.
• Estos métodos, cuando se emplean para extender una clase, plantean un grave problema de estabilidad respecto al versionado: si el implementador de la clase introduce un método de instancia en la clase extendida, dejará de funcionar la extensión, porque el método de instancia tiene la prioridad. Lo peor es que sería muy difícil detectar estos problemas.

De momento, a falta de más análisis, me inclino por sustituir este recurso por implementaciones en interfaces. Es verdad que no son recursos equivalentes, pero la suciedad de los métodos de extensión me aterra.