Constraint in die andere Richtung?

GPC

Chrisi_K schrieb:

Mit Hilfe einer Erweiterungsmethode sollte es erreichbar sein:

public class Test<T>
    {
    }

    public static class TestExtension
    {
        public static void Do<T, U>(this Test<T> test, U x) where T : U
        { }
    }

Gruss Chris

Sehr gute Idee!

Firefighter

GPC schrieb:

Chrisi_K schrieb:
Mit Hilfe einer Erweiterungsmethode sollte es erreichbar sein:
public class Test<T>
    {
    }

    public static class TestExtension
    {
        public static void Do<T, U>(this Test<T> test, U x) where T : U
        { }
    }
Gruss Chris
Sehr gute Idee!

Nein, Beste Idee für diese Problem

Dravere

Die Lösung von Chrisi_K hat mindestens einen Schwachpunkt:
Man muss immer beide Typen angeben. Diese können nicht automatisch deduziert werden.

Und ob es wirklich die beste Idee für dieses Problem ist, wage ich zu bezweifeln. Empfindet dies niemand sonst als unschönen Hack?

Ansonsten: Chapeau Chrisi_K!

Grüssli

Firefighter

Ja das empfand ich anfangs auch als "unschön" aber du hast auf jedenfall mehr Compile-Time Sicherheit als mit dynamic und wieso die Schöne Compile-Time Sicherheit gegen was anderes eintausch?:D

Zeus

Dravere schrieb:

Die Lösung von Chrisi_K hat mindestens einen Schwachpunkt:
Man muss immer beide Typen angeben. Diese können nicht automatisch deduziert werden.

Und ob es wirklich die beste Idee für dieses Problem ist, wage ich zu bezweifeln. Empfindet dies niemand sonst als unschönen Hack?

Ansonsten: Chapeau Chrisi_K!

Grüssli

Hmm, was meinst du? Du muss beide einbinden(include/using). Viel unschönere ist, dass die Methode statisch gebunden ist.

Dravere

Firefighter schrieb:

Ja das empfand ich anfangs auch als "unschön" aber du hast auf jedenfall mehr Compile-Time Sicherheit als mit dynamic und wieso die Schöne Compile-Time Sicherheit gegen was anderes eintausch?:D

Wie wäre es gegen eine andere compiletime sichere Lösung der eigentlich Aufgabe? Ich sage nicht, dass dynamic besser wäre, sondern dass hier eher etwas am Design nicht stimmt. Vielleicht hat sich da jemand zu sehr an die C++ Templates erinnert und dadurch im Gesamten ein schlechtes Design gewählt.

Zeus schrieb:

Hmm, was meinst du? Du muss beide einbinden(include/using).

Ich meine die Generics:

class Base { }
class Derived : Base { }

var t = new Test<Derived>();
t.Do<Derived, Base>();
//   ^^^^^^^  ^^^^

Zeus schrieb:

Viel unschönere ist, dass die Methode statisch gebunden ist.

Was meinst du damit?

Grüssli

Zeus

Ach verdammt, daran hab ich nicht gedacht, ja wirklich Hexenzeug

public class Base { }

    public class Sub : Base { }

    public static class Extension
    {
        public static void Do(this Base test)
        {
            Console.WriteLine("base");
        }

        public static void Do(this Sub test)
        {
            Console.WriteLine("sub");
        }
    }

    public class Program
    {

        static void Main(string[] args)
        {
            var b = new Base();
            var s = new Sub();

            var list = new List<Base>();
            list.Add(b);
            list.Add(s);

            foreach (var element in list)
            {
                element.Do();
            }
            Console.ReadLine();
        }
    }

Mit Extension sollte man vorsichtig sein.

Dravere

Zeus schrieb:

...
Mit Extension sollte man vorsichtig sein.

Achso, dass hast du gemeint. Guter Einwand.

Grüssli

PS: Console.ReadKey(true)

*rant*

Dravere schrieb:

Ich empfehle dynamic zu verwenden
Damit hast du zwar keine Kompilezeitprüfung, aber immerhin eine Laufzeitprüfung und die Komplexität wird reduziert. dynamic wurde ja auch genau für solche Fälle eingeführt.

Omg! Ich wusste gar nicht, dass man so ein schändliches Keyword in die einst so saubere Sprache eingeführt hat. Ich bin enttäuscht - da hämmern alle auf dem alten Visual Basic herum wegen solchen Dingen, und 10 Jahre später ist es der letzte Schrei. Sowas möchte ich auf jeden Fall verhindern.

Da wir eh gerade von schrecklichen Sprach-Features sprechen: Warum gibt es eigentlich Extension-Methoden, aber keine Extension-Properties? Die wären manchmal auch nützlich :p

Dravere schrieb:

Vielleicht hat sich da jemand zu sehr an die C++ Templates erinnert und dadurch im Gesamten ein schlechtes Design gewählt.

Ja, ich habe in den vergangenen Jahren mehr mit C++ zu tun gehabt als mit C#, und bin insbesondere von Templates sehr angetan. Und hier handelt es sich primär um eine Machbarkeitsstudie - welche jedoch teilweise bereits unter realen geschäftlichen Bedingungen eingesetzt wird. Das Sommerloch ist die ideale Experimentierzeit. Und dabei kommen dann eben solche Projekte raus

Ich versuche gerade, meine Schnittstellen in ko- und kontravariante Teile aufzuteilen. Mal schauen, wo ich dann hinkomme

Dravere

/rant/ schrieb:

Omg! Ich wusste gar nicht, dass man so ein schändliches Keyword in die einst so saubere Sprache eingeführt hat.

Richtig angewendet ist das Keyword der Hammer. Es ist gerade für dynamischen Code gedacht. Wenn du dir zum Beispiel IronPtyhon anschaust, dann kannst du eine Klasse in IronPython zur Laufzeit generieren und sie dann über dynamic in C# verwenden. Früher hättest du dies nur über aufwändige Reflection machen können, welche von der Laufzeit auch nicht gut optimiert hätte werden können.

/rant/ schrieb:

Da wir eh gerade von schrecklichen Sprach-Features sprechen: Warum gibt es eigentlich Extension-Methoden, aber keine Extension-Properties? Die wären manchmal auch nützlich :p

Wurde soweit ich weiss schon mal überprüft. Hier:
http://blogs.msdn.com/b/ericlippert/archive/2009/10/05/why-no-extension-properties.aspx

/rant/ schrieb:

Dravere schrieb:

Vielleicht hat sich da jemand zu sehr an die C++ Templates erinnert und dadurch im Gesamten ein schlechtes Design gewählt.

Ja, ich habe in den vergangenen Jahren mehr mit C++ zu tun gehabt als mit C#, und bin insbesondere von Templates sehr angetan.

Gilt bei mir auch und ist daher keine Entschuldigung

Grüssli