Warum einen wenn sie auch viele haben kann?

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

  • macmoonshine schrieb:

    Ja, das ist schon klar.

    Den Link habe ich nicht unbedingt deinetwegen gepostet, sondern damit auch andere, z.B. schweigende Mitleser, die Möglichkeit haben, sich genauer zu informieren, worum es dabei eigentlich geht.^^

    macmoonshine schrieb:

    Aber wieso nicht auch

    Wieso nicht auch [Foo conformsToProtocolOrMaybeNot:@protocol(BarProtocol)]? :)
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • torquato schrieb:

    Den Link habe ich nicht unbedingt deinetwegen gepostet, sondern damit auch andere, z.B. schweigende Mitleser, die Möglichkeit haben, sich genauer zu informieren, worum es dabei eigentlich geht.^^
    Steht ja auch in in den verlinkten Release Notes drin, aber es sollte ja auch nicht zu einfach sein. Mitraten und gewinnen ist ja das Motto. ;)
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Welchen Typ hat denn nun b?

    In der Tat. Die Frage ist vollkommen berechtigt. War auch mir so isoliert auf dem ersten Blick nicht sofort klar.
    Auf dem zweiten Blick ergibt sich das aber eigentlich von selbst.

    Testcase:

    Quellcode

    1. protocol A {}
    2. protocol B {}
    3. struct Foo {}
    4. struct Bar: A, B {}
    5. let array: [Any] = [Foo(), Bar()]
    6. for value in array {
    7. let b = value as? A & B
    8. print(b.self)
    9. }
    Alles anzeigen

    ergibt:

    Quellcode

    1. nil
    2. Optional(Bar())
    Natürlich ist b vom gleichen Typ wie value – welcher auch immer das sein mag. Und weil es ein Optional-Konstrukt ist, eben ein Optional davon. ;)

    Interessanter ist eigentlich die Frage: Welchen Typ hat var foo: A & B? Oo
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • macmoonshine schrieb:

    t-no schrieb:

    Das zeigt schonmal, dass der Sinn hinter "A & B & C" intuitiv verständlich ist;
    Nein, gerade in einer statischen Programmiersprache ist das sehr seltsam. Welchen Typ hat denn nun b?
    Ist das eine rhetorische Frage?
    "Float | Double" wäre eine Fließkommazahl
    "UIViewController & UITableViewDatasource" ist ein Viewcontroller, der zusätzlich Daten für einen TableView bereithält...
    Was A, B und C sind weiss ich aber nicht... ;)
  • t-no schrieb:

    Ist das eine rhetorische Frage?
    Nein

    Das & könnte übrigens auch als Durchschnitt gemeint sein: Der Typ, der entsteht, indem du nur die gemeinsamen Eigenschaften der Typen A, B und C nimmst.

    t-no schrieb:

    "Float | Double" wäre eine Fließkommazahl
    Das ist richtig dünnes Eis, insbesondere wenn die beteiligten Typen Klassen sind. ;)

    t-no schrieb:

    "UIViewController & UITableViewDatasource" ist ein Viewcontroller, der zusätzlich Daten für einen TableView bereithält...
    Das hört sich eher nach einem Prädikat als nach einem Typ an.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Ja, das ist schon klar. Aber wieso nicht auch

    Quellcode

    1. let b = value as? A | B | C
    oder

    Quellcode

    1. let b = value as? A ^ B ^ C
    Praktisch fände ich auch:

    Quellcode

    1. let b = value as? (currentDay() % 2 == 0 ? A : B)
    ;)
    Also spätestens jetzt habe ich nicht mal mehr Lust mich irgendwann mit Swift zu beschäftigen und werde wohl bis an mein Lebensende bei Obj-C bleiben...
    Aber der größte Nachteil scheint mir der immer unlesbarere Code zu sein, der immer weniger Ähnlichkeiten mit anderen bekannten Sprachen hat.
    Code in Obj-C ist (wenn man ein bischen C kann und die [] verstanden hat) irgendwie selbsterklärend. Das ist mir viel wichtiger als manche trickreiche Neuerungen...
    Obj-C scheint mir "rock solid" und Swift so (be)greifbar wie Sand.
  • Ich kann ja den Beweggrund hinter diesem Proposal irgendwo nachvollziehen, aber statt let x: protocol<A, B, C> = something ein let x: A & B & C = something halte ich für völlig dämlich.
    Ein typisches Feature der Operatorenübrladung: Was auch immer mit A, B und C geschieht, hängt nicht vom verbindenden Operatoren ab, sondern vom Kontext.

    Für mich ist 'Komma zählt auf, & verknüpft binär' einfacher zu merken als '& verknüpft binär, außer bei Zuweisungen, da kombiniert es Protokolle'

    Wer auch immer bei Swift für die 'Vereinfachung' zuständig ist verwechselt da was.
    Dinge werden nicht einfacher, wenn sie täuschend gleich aussehen aber sich völlig unterschiedlich verhalten, nur um ein zusätzliches Zeichen einzusparen.

    Der Unterschied ist doch beim Querlesen echt nicht offensichtlich.

    Brainfuck-Quellcode

    1. // Ja, der Codetyp 'Brainfuck' ist Absicht.
    2. let oans = a & b & c
    3. let zwo: A & B & C = values


    zwo ist also vom Typ A. Und B. Und C. Und AB. Und AC. Und BC. Und ABC. Argh.

    Müsste hier nicht konseqenterweise auch Folgendes funktioneren?

    Brainfuck-Quellcode

    1. // Alte Form
    2. var eins, zwei, drei = 0
    3. // Verbesserte Formel
    4. var uno & dos & tres = 0


    Falls ich dazu ein Proposal übersehen habe bitte ich um Erschießung. :cursing:
    «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
  • Also was mich ganz unabhängig von irgendwelchen immer wieder neuen Säuen, die gerade vom Swift-Team durchs Dorf getrieben werden, davon abhält, auf Swift umzusteigen, ist die unfertige (um nicht zu sagen kaputte) Toolchain. Richtig geil ist das Refactoring in Xcode (geht nach wie vor nur mit Objective-C, aber auch das ist unbrauchbar). Wenn Apple doch nur 1% der Swift Ressourcen in das Refactoring stecken würde...

    Objective-C mag in die Jahre gekommen sein, aber es ist simpel, es gibt AppCode und es funktioniert. Ich wage sogar zu behaupten, dass eine ordentliche IDE mehr Produktivität bietet, als eine an allen Ecken und Enden immer wieder neu aufgebohrte Sprache.
  • Markus Müller schrieb:

    Ich wage sogar zu behaupten, dass eine ordentliche IDE mehr Produktivität bietet, als eine an allen Ecken und Enden immer wieder neu aufgebohrte Sprache.
    Als Entwickler wünscht man sich und braucht auch eine gewisse Stabilität in der Sprache. Selbst mit den besten Konvertern macht eine jährliche Migration auf den neusten Sprachstandard auf die Dauer keinen Spaß. Abgesehen davon ist das viel Aufwand, den einem auch kein Kunde bezahlt.

    Markus Müller schrieb:

    Wenn Apple doch nur 1% der Swift Ressourcen in das Refactoring stecken würde...
    Ja, Xcode hinkt, zumindest was den Editor angeht, anderen IDEs um Jahre hinterher. Da werden auch die verkrüppelten Xcode Extensions nicht viel daran ändern.
    „Meine Komplikation hatte eine Komplikation.“
  • Marco Feltmann schrieb:

    Ein typisches Feature der Operatorenübrladung: Was auch immer mit A, B und C geschieht, hängt nicht vom verbindenden Operatoren ab, sondern vom Kontext.
    Das bringt meine Kritik gut auf den Punkt: eine Sprache, die überhaupt Operatorenüberladung zuläßt, fördert völlig unlesbaren Code. Dann nehme ich doch gleich LISP oder APL :)

    Fortrackz schrieb:

    Ist eine Programmiersprache bei der man ständig rätseln muss was welchen Typ hat nicht kompletter Bullshit?
    Vollste Zustimmung.

    Peter Bichsel hat das schon lange auf den Punkt gebracht: deutschunddeutlich.de/contentLD/GD/GT67cTischistTisch.pdf ist aber in der Informatik leider viel zu wenig bekannt.

    Übrigens widersprechen solche Typ-Automatismen doch dem Prinzip: "Ich will dass die Maschine dies und das macht". D.h. man kämpft nicht mit seiner Aufgabenstellung, sondern der im Compiler eingebauten und hinter kryptischer Syntax versteckten Automatik. Als Game ist das ja ganz nett, aber nicht als Werkzeug.

    Markus Müller schrieb:

    Objective-C mag in die Jahre gekommen sein, aber es ist simpel, es gibt AppCode und es funktioniert. Ich wage sogar zu behaupten, dass eine ordentliche IDE mehr Produktivität bietet, als eine an allen Ecken und Enden immer wieder neu aufgebohrte Sprache.
    Obj-C funktioniert einfach und tut was es soll. Und 20 Jahre alter Code ist noch problemlos lesbar. Und sogar wiederverwendbar. Was will man eigentlich mehr?

    Verbesserungen am IDE wären schön, wenn auch nicht unbedingt notwenig.
  • hns schrieb:

    Übrigens widersprechen solche Typ-Automatismen doch dem Prinzip: "Ich will dass die Maschine dies und das macht". D.h. man kämpft nicht mit seiner Aufgabenstellung, sondern der im Compiler eingebauten und hinter kryptischer Syntax versteckten Automatik. Als Game ist das ja ganz nett, aber nicht als Werkzeug.
    Ich finde da Swift (und auch C++ mit auto) auch widersprüchlich: Einerseits soll durch statische Typisierung jederzeit der Typ bekannt sein, um dadurch Fehler zu vermeiden. Andererseits versteckt die Typeinference den Typen vor dem Programmierer. Das erschwert das Lesen fremden Codes unheimlich, insbesondere wenn der Programmierer bei der Wahl von Variablennamen sehr schlampig war. Swift gaukelt mit seinem let und var dem Programmierer vor, es wäre eine Skriptsprache, und haut ihm aber bei Fehlern in die Fresse, wie eine statische Programmiersprache.
    „Meine Komplikation hatte eine Komplikation.“
  • Marco Feltmann schrieb:

    Ich kann ja den Beweggrund hinter diesem Proposal irgendwo nachvollziehen, aber statt let x: protocol<A, B, C> = something ein let x: A & B & C = something halte ich für völlig dämlich.
    Ein typisches Feature der Operatorenübrladung: Was auch immer mit A, B und C geschieht, hängt nicht vom verbindenden Operatoren ab, sondern vom Kontext.

    Für mich ist 'Komma zählt auf, & verknüpft binär' einfacher zu merken als '& verknüpft binär, außer bei Zuweisungen, da kombiniert es Protokolle'

    Wie gut, daß in der 'Besten Programmiersprache aller Zeiten' solche Zeichen _immer_ nur eine Funktion haben.
    Hey, Moment mal. War da nicht was?

    &: Ist bitweiser Logikoperator UND für Pointer-Voodoo zuständig UND in doppelter Ausführung auch noch ein boolscher Operator.
    *: Ist ein arithmetischer Operator UND man definiert damit Pointer UND man dereferenziert damit Pointer.
    ^: Ist bitweiser Logikoperator UND dann noch was mit Blocks.

    :P

    Marco Feltmann schrieb:

    Wer auch immer bei Swift für die 'Vereinfachung' zuständig ist verwechselt da was.
    Dinge werden nicht einfacher, wenn sie täuschend gleich aussehen aber sich völlig unterschiedlich verhalten, nur um ein zusätzliches Zeichen einzusparen.

    Um das Swift-Bashing ein bißchen anzukurbeln. Ich finde das noch ziemlich mau hier in diesem Thread. :)

    Der eigentliche Knackpunkt ist, daß man bei mehrfacher Protokollkonformität einmal & verwenden muß extension Array where Element: A & B {} und einmal Kommata struct Bar: A, B {}.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?