Neulich im Sandkasten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Neulich im Sandkasten

    Eigentlich hat meine Farbliste 147 Einträge. Als ich diese Fehlermeldung („expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions“) bei der ursprünglichen Liste bekommen habe, wollte ich zuerst eine binäre Suche starten, habe dann aber mit einem Eintrag (funktioniert) und danach zwei Einträgen (funktioniert nicht) angefangen. Wenn ich für die Array-Elemente den Typ Double verwende geht's auch mit der gesamten Liste. Float-Literale unterstützt Swift im Gegensatz zu anderen Sprachen nicht. Als Workaround muss ich also entweder Double verwenden, die Divisionen durch ihr jeweiliges Ergebnis ersetzen oder jeden Double-Ausdruck auf Float casten. Letzteres erhöht die Lesbarkeit natürlich ungemein.

    Was sieht man nun an diesem Beispiel?
    1. Type Inference ist eine recht aufwändige Geschichte. Schon kleine und selbst regelmäßige Ausdrücke können den Compiler ins Schwitzen bringen. Der 6.3beta-Compiler hängt sich damit sogar auf...
    2. Type Inference ist Mist (siehe 1.): Anstatt das die linke Seite vorschreibt, was der Compiler auf der rechten Seite zu tun hat (Double-Ausdrücke in Floats konvertieren), versucht der Compiler krampfhaft selber herauszufinden, welchen Typ die rechte Seite hat und scheitert schon an einer geringen Komplexität. Der gesamte Baum dieses Ausdrucks dürfte so ca. 25 Knoten enthalten.
    3. Static Typing ist Mist: Ich habe als Workaround den Typ [String:[Double]] verwendet. Wozu brauche ich dann aber Static Typing, wenn ich die Typen verwenden muss, die der Compiler lieber mag.
    Dateien
    • colors.png

      (105,11 kB, 592 mal heruntergeladen, zuletzt: )
    „Meine Komplikation hatte eine Komplikation.“
  • Ernsthaft jetzt? Swift scheint ja echt toll zu sein, sollte ich mir doch mal anschauen :)

    Zu (2) (und auch 3), ich würde erwarten, dass nur sichergestellt wird, dass das was auch immer auf der rechten Seite steht, der linken zuweisbar ist - von daher würde ich das jetzt so auch nicht als schlimm ansehen. Wenn es funktionieren würde..
    C++
  • zerm schrieb:

    Ernsthaft jetzt? Swift scheint ja echt toll zu sein, sollte ich mir doch mal anschauen

    Ironie an oder aus? ;)

    zerm schrieb:

    Wenn es funktionieren würde..

    Das ist ja gerade der Knackpunkt: Das ist ein inhärentes Problem der Type Inference. Selbst wenn Apple dieses Beispiel zum Laufen brächte, kann man es wieder leicht verkomplizieren, und dadurch den Compiler aus der Bahn werfen.
    „Meine Komplikation hatte eine Komplikation.“
  • zerm schrieb:

    Zu (2) (und auch 3), ich würde erwarten, dass nur sichergestellt wird, dass das was auch immer auf der rechten Seite steht, der linken zuweisbar ist - von daher würde ich das jetzt so auch nicht als schlimm ansehen.

    Ach ja

    Quellcode

    1. let kLongFloatColorValues = ... as [String:[Float]]
    funktioniert übrigens auch nicht.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Ironie an oder aus?

    Was meinst Du wohl :D

    macmoonshine schrieb:

    Das ist ja gerade der Knackpunkt: Das ist ein inhärentes Problem der Type Inference. Selbst wenn Apple dieses Beispiel zum Laufen brächte, kann man es wieder leicht verkomplizieren, und dadurch den Compiler aus der Bahn werfen.

    TypeScript bekommt es ja problemlos hin, z.B. - oder ist da was anderes dran? Ich hab jetzt kein grossartiges Problem mit Typinference, wenns funktioniert.
    C++
  • macmoonshine schrieb:

    Ja, das Ganze soll unabhängig vom UIKit und vom AppKit sein. Das Ganze hat erstmal nichts mit Malen zu tun.


    Dann fallen wir zwei Wege ein:
    1. Farben speichern als hex-Werte und zwei (oder mehr) Funktionen schreiben, die daraus ein UIColor und eine NSColor oder was auch immer machen.
    2. Eine eigene Farb-Klasse schreiben, die auf iOS zu UIColor wird und auf AppKit zu NSColor wird.

    Ist nicht das viel größere (und auch absurdere) Problem, dass für sowas einfaches wie eine Farbe in UIKit und in AppKit unterschiedliche Klassen existieren?
  • dasdom schrieb:

    Farben speichern als hex-Werte und zwei (oder mehr) Funktionen schreiben, die daraus ein UIColor und eine NSColor oder was auch immer machen.

    Wie gesagt: Ich habe funktionierende Alternativen, und will auch erstmal überhaupt keine UIKit- oder AppKit-Objekte haben.

    dasdom schrieb:

    Eine eigene Farb-Klasse schreiben, die auf iOS zu UIColor wird und auf AppKit zu NSColor wird.

    Genau, ich habe eine eigene Klasse, und die Umwandlung in UIKit- oder AppKit-Objekte ist dabei vollkommen irrelevant.

    dasdom schrieb:

    Ist nicht das viel größere (und auch absurdere) Problem, dass für sowas einfaches wie eine Farbe in UIKit und in AppKit unterschiedliche Klassen existieren?

    Vielleicht; das hat aber nichts mit meinem Anwendungsfall zu tun, genauso wenig, wie das Compilerproblem etwas mit Farben zu tun hat.
    „Meine Komplikation hatte eine Komplikation.“
  • Ich glaube du solltest bei Objective-C bleiben. :)

    Allgemein habe ich das Gefühl, dass Swift nur für neue Implementierungen taugt. Funktionierender Code sollte (vorerst) nicht nach Swift portiert werden. Auch das Mischen von Objective-C mit Swift ist problematisch, denn, wenn man Swift richtig nutzt, hat man schnell Typen (Enums und Structs) auf die man von Objective-C aus nicht mehr zugreifen kann.
  • zerm schrieb:

    Was meinst Du wohl :)

    :D

    zerm schrieb:

    TypeScript bekommt es ja problemlos hin, z.B. - oder ist da was anderes dran? Ich hab jetzt kein grossartiges Problem mit Typinference, wenns funktioniert.

    Ich keine TypeScript nicht. Wenn es dort nur einen Typ für Zahlen gibt, vereinfacht das das Problem ja erheblich. Der Swift-Compiler hat ja auch kein Problem mit dem Ausdruck, wenn ich auf der linken Seite [String:[Double]] haben will oder die Divisionen ausrechne. Das Problem ließe sich wahrscheinlich auch durch die Unterstützung von Float-Literalen auch compilerseitig beheben.
    „Meine Komplikation hatte eine Komplikation.“
  • dasdom schrieb:

    Ich glaube du solltest bei Objective-C bleiben. :)

    Ich bin ein weltoffener Mensch. Natürlich beschäftige ich mich mit Swift. Deswegen muss ich aber die Mängel nicht übersehen.

    dasdom schrieb:

    Allgemein habe ich das Gefühl, dass Swift nur für neue Implementierungen taugt. Funktionierender Code sollte (vorerst) nicht nach Swift portiert werden. Auch das Mischen von Objective-C mit Swift ist problematisch, denn, wenn man Swift richtig nutzt, hat man schnell Typen (Enums und Structs) auf die man von Objective-C aus nicht mehr zugreifen kann.

    Das ist neuer Code, und da gibt es keinen Objective-C-Vorgänger. Das ist bis jetzt auch noch ein reines Swift-Projekt.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Ich keine TypeScript nicht. Wenn es dort nur einen Typ für Zahlen gibt, vereinfacht das das Problem ja erheblich. Der Swift-Compiler hat ja auch kein Problem mit dem Ausdruck, wenn ich auf der linken Seite [String:[Double]] haben will oder die Divisionen ausrechne. Das Problem ließe sich wahrscheinlich auch durch die Unterstützung von Float-Literalen auch compilerseitig beheben.

    Stimmt, das eigentliche Problem ist eher das Fehlen von Float-Literalen. Nur ist es noch extra merkwürdig, dass der Ausdruck für Swift so komplex zu sein scheint, dass er ihn nicht evaluiren kann. Ich mein, Typ-Inferenz ist ja nichts besonders neues und besonders komplex ist der Ausdruck ja nun wirklich nicht (mit C++ templates kann man den compiler mal richtig fordern ;) und das geht ja auch)

    Btw, TypeScript finde ich recht schön. Ist nur ein wenig anstrengend, in einer so dynamischen Sprache wie JavaScript konsequente Typisierung durchzuziehen, weshalb man praktisch doch zumal gezwungen wird, das ganze zu umgehen :/
    C++
  • macmoonshine schrieb:

    ...und die eine oder andere Kaffeepause rausschlagen.

    Ja :) Lohnt sich aber in der Regel.

    macmoonshine schrieb:

    Sobald es schwierig wird, muss man doch wieder zu Fuß gehen. Wobei wir wieder beim OP sind...

    Jein. Ist halt schwer, von JavaScript-Denkweise ganz wegzugehen, bzw. doch arg nervig, soviel Typ-Definitionen machen zu müssen, und oft ist mir noch nicht klar, was dort das beste Vorgehen ist (ist ja auch noch eine relativ neue Sprache, da haben sich noch nicht so viele Standards etabliert). Bspw erweitert man so gern mal eben auf die Schnelle eine Funktion (uh, Klasse?) und will dann nicht unbedingt noch alles umstellen, damit man wieder eine korrekte Typdefinition hat...
    C++
  • zerm schrieb:

    Bspw erweitert man so gern mal eben auf die Schnelle eine Funktion (uh, Klasse?) und will dann nicht unbedingt noch alles umstellen, damit man wieder eine korrekte Typdefinition hat...

    Prototypbasierte Sprache. Was soll die mit einer Klasse?
    Offenbar sollte auch Microsoft die Finger von neuen hippen Programmiersprachen lassen…

    (Es heißt immer noch Objektorientierung, nicht Klassenorientierung. Verdammt.)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • zerm schrieb:

    Ernsthaft jetzt? Swift scheint ja echt toll zu sein, sollte ich mir doch mal anschauen :)

    Zu (2) (und auch 3), ich würde erwarten, dass nur sichergestellt wird, dass das was auch immer auf der rechten Seite steht, der linken zuweisbar ist - von daher würde ich das jetzt so auch nicht als schlimm ansehen. Wenn es funktionieren würde..
    Das ist ja bei jeder Sprache so.

    Wie ich mit Christian gezeigt habe, ist das wirklich üble, dass zusammen mit Overloading der Type des LValue bestimmt, was an Methoden im RValue ausgeführt wird. Das heißt, dass der Typ im LValue den Kontrollfluss bei der Erzeugung des RValue bestimmt. Das kann weder jemand durchblicken, noch kann man es den Leuten theoretisch vermitteln. Wenn jetzt auch noch der LValue selbst Typvielfalt bildet, etwa als Parameter einer überladenen Methode, bekommt man das Ganze wohl nur noch mit hohen Dosen LSD in den Griff.

    Völlig schwachmatisch.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?