Swift Einschätzung

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

  • Die Aussagen sind in der Tat lustig. Auch zu @Marco Feltmann: Modern wird es nun einmal genannt und wenn man sinniert, was modern sein soll, so kann es ja nur die statische Typisierung sein. Aber die auch nicht.

    Die ach so bequemen Inferred-Types funktionieren genau dann, wenn es extrem einfach bleibt. Gemeinsam mit der "Typrückschluss", Templates und Überladen ist das dagegen lustig und dürfte innerhalb kürzester Zeit für mehr Fehler verantwortlich sein, als alle dynamische Typisierung es jemals war. Wer irgendwann mal komplett anderen Code im ganzen Projekt bekommt, bloß weil er eine Überladung hinzugefügt hat, schlägt dann hier auf. Aber dazu ja bereits auf der Macoun.

    Christian hat dann übrigens von einem "Kritiker" unseres Vortrages einen Tweet bekommen, indem er zugibt in einem (sehr einfachen Fall) den falschen Typen erhalten zu haben. Er schrieb "// Compiler Bug" rein. Christian versuchte ihm zu erklären, dass es sich nicht um einen Bug, sondern um das Konzept von Swift handelt. Hat der nicht verstanden.

    Überhaupt haben wir zahlreiche Mitteilungen bekommen, wir hätten nur Bugs demonstriert. Tatsächlich befand sich im gesamten Vortrag ein einziger Bug, den wir dann auch noch virtuell hinweggedacht haben, weil uns das in der Tat zu affig war. Offenkundig raffen die Leute gar nicht, dass das dargestellte Verhalten von Swift in unserem Vortrag vollständig beabsichtigt ist.
    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"?
  • Markus Müller schrieb:

    Also ich weiß nicht, was ihr alle habt. Ist ein bisschen so wie mit den alten Leuten: "Früher war alles besser, sogar die Zukunft..." :)

    Mir gefallen etliche Sachen an Swift, und ja, die Typsicherheit gehört dazu. M.M.n. eine willkommene Entrümpelung von Objective-C was ja aber nicht sofort unbrauchbar wird, nur weil es eine zweite Apple-Sprache gibt (wer mag z.B. das NSNumber boxing, um primitive values in den Cocoa collections verwenden zu können?).

    Die Änderung des Sprachkonzeptes von dynamischer auf statische Typisierung ist wohl etwas mehr als "Entrümpelung". Sie ist die Abkehr von dem, was Kay Objektorientierung genannt hat.

    Und ja, Boxed-Expressions nerven. Man muss wirklich @() schreiben. Gut, meinetwegen ändert man das. Hätte man auch in Objective-C machen können. Mit statischer Typisierung hat das wenig zu tun.

    Heute übrigens habe ich mich darüber geärgert: Ich hatte eine Objektklasse, so etwas ähnliches wie NSManagedObject, und die hatte eine ID die ich mit long typisiert hatte. Dann hatte ich eine Proxyklasse, die für das Objekt steht und stattdessen installiert wird. Hatte auch eine ID mit dem Typen id(letztlich NSNumber). Epic-Fail. Wäre mir mit Swift nicht passiert.










    Wäre mir mit Swift vor allem deshalb nicht passiert, weil sich gar keine generischen, transparenten Proxies programmieren lassen.
    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"?
  • Ich weiß auch noch immer nicht, welches Problem die Type-Inference letztendlich lösen soll. Das ich mich nicht darum zu kümmern brauche, mit welchen Typen mein Code arbeitet? Ist das nicht schon fast ein Widerspruch zur Typsicherheit, weil dabei unerwartete Typen rauskommen können?

    EDIT: Wenn sich Swift mit schlechten Programmierstilen (z. B. Operator- und Methoden-Overloading) vereinigt, ist das wahrscheinlich häufiger der Fall.
    „Meine Komplikation hatte eine Komplikation.“
  • Kümmern musst du dich ja darum. Weil der Code arbeitet. Bei einer Division willst du ja wissen, ob die auf einer Ganzzahl oder einer Fließkommazahl ausgeführt wird.

    Der einzige Sinn bringende Nutzen ist Bequemlichkeit: Du musst nicht dazu schreiben, was es sein soll, wenn es sich ergibt:

    Quellcode

    1. let a = 5; // Offenkundig soll a eine Ganzzahl sein.

    Das ist schon problematisch, wenn es jetzt weitergeht:

    Quellcode

    1. let b = 7;
    2. let c = a/b;

    Na, wirklich so gewollt?
    Gut. Was aber, wenn weitere Mechanismen der – äh – Lesbarkeit hinzukommen:

    Quellcode

    1. let d = func(a);

    d hat welchen Typen? Das erfahren wir erst, wenn wir func() suchen. Okay.

    Quellcode

    1. let e = func2(d);

    Ah, ist ja hier wieder dasselbe. Ich finde auch ein func2(), welches einen float nimmt und liefert. Super, alles klar. Nö, doch nicht. Denn es gibt noch ein func2(), welches einen int liefert und einen int nimmt (Überladung). Welches func2() wird denn jetzt benutzt? Das hängt davon ab, was d für einen Typen hat und dies hängt wiederum davon ab, was func() für einen Typen hat.

    Ich kann mich gar nicht entscheiden, alles so schön bunt hier.
    Ich glotz Swift-Code!
    Ich glotz Swift-Code!

    Nina Hagen

    Christian hat sich ja die Mühe gemacht, das in einem Beispiel von 4 verschachtelten Methoden aufzuzeichnen. Das kann kein Mensch lesen. Das ist ein Feature für Compiler, nicht für Programmierer. Wir machen es, weil es geht.

    Übrigens gibt es das ja schon in Objective-C, eigentlich C, nämlich bei Blocks. Deren Rückgabetyp wird vom Typen des return Argumentes impliziert. Geile Nummer, darf ich das return suchen. Aber besser: Weil C schwach typisiert ist (Skalare können implizit konvertiert werden), widerspricht das diametral der Funktionsweise des C'schen Typsystems. Das ist ja dann auch schnell geändert worden, so dass man nunmehr den Typen explizieren kann.

    Dass es in Swift noch das ganze Inferring "rückwärts" gibt, was wohl keine andere Programmiersprache hat, macht die Sache komplizierter. Jetzt darf ich rückwärts lesen, welche meiner überladenen Methoden ausgeführt wird.

    Ach, ja, zur Klarstellung: In diesem Beitrag befindet sich kein Compiler-Bug. Das soll genau so sein.
    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"?
  • Amin Negm-Awad schrieb:

    Ah, ist ja hier wieder dasselbe. Ich finde auch ein func2(), welches einen float nimmt und liefert. Super, alles klar. Nö, doch nicht. Denn es gibt noch ein func2(), welches einen int liefert und einen int nimmt (Überladung). Welches func2() wird denn jetzt benutzt? Das hängt davon ab, was d für einen Typen hat und dies hängt wiederum davon ab, was func() für einen Typen hat.

    Genau, und mit überladenen Operatoren wird das richtig lustig. Das gibt es dann den +-Operator 50 mal in Swift, 27 mal in eigenen Klassen und 322 mal in Third-Party-Libs. Da kann das schon dauern, bis man raushat, was bei theCount + " users with birthdate " + theDate rauskommt.
    „Meine Komplikation hatte eine Komplikation.“
  • Bewertet ihr die Sprache wirklich an Hand dessen, was man damit so insgesamt mit genügend krimineller Energie syntaktisch komplett falsch machen könnte?
    «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
  • Die ganzen Skript Kiddies, welche sich über Swift so sehr freuen, werden es schon irgendwie hin bekommen.

    Fragt sich nur ob der App Store dann in Zukunft auch Apps oder nur noch "J*mb* Style" Schrot enthält.

    Hauptsache Apple schafft den nächsten Meilenstein in Form von 2, 3, 5 oder sogar 10 Millionen Apps im Store und liegt vor Android. :D

    Ich kann Objective-C und finde es sehr schön und angenehm damit zu entwickeln. Somit werde ich es auch weiterhin nutzen. Sollte diese Option von Apple einmal gekickt werden, dann muss ich halt schauen, ob ich in den sauren Apple :D Swift beiße oder mir etwas anderes überlegen.
  • Marco Feltmann schrieb:

    Bewertet ihr die Sprache wirklich an Hand dessen, was man damit so insgesamt mit genügend krimineller Energie syntaktisch komplett falsch machen könnte?
    Nein, sondern nach dem, was passiert.

    Es passiert tatsächlich, dass Leute Strings mit + verketten. Das ist sogar ein gern genommenes Beispiel.

    Es passiert wirklich, dass Leute Operatoren in Libs erweitern. Dazu ist es ja da.

    Es passiert wirklich, dass Leute Methoden überladen. Dazu ist es ja da.

    Es geht hier wie gesagt nur um den intendierten Einsatz. Der obige Code enthält überhaupt nichts Besonderes. Hier noch einmal zusammengefasst (war übrigens ein Typo drin):

    Quellcode

    1. let a = 5;
    2. let b = 7;
    3. let c = a/b;
    4. let d = func(c);
    5. let e = func2(d);


    Ich kann nicht sehen, wie hier jemand kriminelle Energie hat walten lassen. Einfacher und intendierter geht es ja kaum.
    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"?
  • Marco Feltmann schrieb:

    Bewertet ihr die Sprache wirklich an Hand dessen, was man damit so insgesamt mit genügend krimineller Energie syntaktisch komplett falsch machen könnte?

    Ach, früher fand' ich Operator-Overloading auch mal eine ganz tolle Sache. Wenn ich sehe, was es für tolle Swift-Beispiele dafür im Netz gibt, ist das eine arge Befürchtung meinerseits. Mein Beispiel mit dem +-Operator ist ja kein akademisches Konstrukt. So etwas in der Art kommt wahrscheinlich zig-fach in den meisten größeren Programmen vor.

    Core-Graphics ist übrigens mit Swift auch eine ultra-spannende Sache: CGFloat basiert maschinen-abhängig entweder auf Float (32 Bit) oder Double (64 Bit). Das ist aber ein eigener Typ!

    Da muss man dann auf einmal casten:

    Quellcode

    1. return CGPoint(x:theCenter.x + inRadius * CGFloat(sin(inAngle)), y:theCenter.y - inRadius * CGFloat(cos(inAngle)))

    Der entsprechende Obj-C-Code dazu sieht so aus:

    Quellcode

    1. CGPointMake(theCenter.x + inRadius * sin(inAngle), theCenter.y – inRadius * cos(inAngle));
    „Meine Komplikation hatte eine Komplikation.“
  • Amin Negm-Awad schrieb:

    Der einzige Sinn bringende Nutzen ist Bequemlichkeit: Du musst nicht dazu schreiben, was es sein soll, wenn es sich ergibt:


    Ok, Du magst Type Inference nicht. Musst Du ja auch nicht benutzen. Das Problem hast Du in Objective-C auch:

    Quellcode

    1. // test.h
    2. @import Foundation;
    3. extern NSArray *createTest(void);


    Quellcode

    1. // test.m
    2. #import "test.h"
    3. @interface TestClass : NSObject
    4. - (int)currentPoint;
    5. @end
    6. @implementation TestClass
    7. - (int)currentPoint {
    8. return 0;
    9. }
    10. @end
    11. NSArray *createTest(void) {
    12. return @[[[TestClass alloc] init]];
    13. }
    Alles anzeigen


    Quellcode

    1. // main.m
    2. @import AppKit;
    3. #import "test.h"
    4. int main(int argc, const char * argv[]) {
    5. @autoreleasepool {
    6. NSArray *values = createTest();
    7. int result = [[values objectAtIndex:0] currentPoint];
    8. NSLog(@"Value: %d", result);
    9. }
    10. return 0;
    11. }
    Alles anzeigen


    Und jetzt?
  • [SteveJ]
    Ich übersetze Dein Gestammel mal in Laufzeitkram.

    Quellcode

    1. // test.h
    2. @import Foundation;
    3. extern void *createTest(void);


    Quellcode

    1. // test.m
    2. #import "test.h"
    3. @interface TestClass : NSObject
    4. - (int)currentPoint;
    5. @end
    6. @implementation TestClass
    7. - (int)currentPoint {
    8. return 0;
    9. }
    10. @end
    11. void *createTest(void) {
    12. return @[[[TestClass alloc] init]];
    13. }
    Alles anzeigen


    Quellcode

    1. // main.m
    2. @import AppKit;
    3. #import "test.h"
    4. int main(int argc, const char * argv[]) {
    5. @autoreleasepool {
    6. void *values = createTest();
    7. int result = [[values objectAtIndex:0] currentPoint];
    8. NSLog(@"Value: %d", result);
    9. }
    10. return 0;
    11. }
    Alles anzeigen


    Und jetzt siehst Du auch, dass Dein 'Und jetzt?' Blödsinn ist.

    Denn was Du bekommst ist hier ganz eindeutig und reproduzierbar beim ersten und jeden weiteren Start der Anwendung:
    [TestClass] does not respond to selector -objectAtIndex:
    Es ist absolut ausgeschlossen, dass der Compiler an der Stelle ein NSArray erwartet, nur weil Du es im Code so hingeschrieben hast. Ebenso ist es ausgeschlossen, dass der Compiler sich an der Stelle auf das Vorhandensein eines NSArray verlässt, nur weil Du es im Code so hingeschrieben hast.
    Swift hingegen trifft diese Annahmen, stellt diese Erwartungen und fordert diese Verlässlichkeit.

    Übrigens:
    Wenn Du C Funktionen nutzen möchtest, um das Verhalten des Objective-C Compilers zu umgehen, dann darfst Du das gern tun.
    Wenn Du Warnungen ignorieren möchtest, die Dich auf einen fehlerhaften Rückgabewert hinweisen, dann darfst Du das gern tun.
    (Denn clang warnt Dich ganz sicher, dass -createTest() als NSArray * definiert ist aber TestClass * zurückgibt.)

    Die Sprache kann nichts dafür, dass Du sie total bescheuert einsetzt.
    (Swift kann auch nichts dafür, wenn Andere sie total bescheuert einsetzen. Das versuche ich ja mitzuteilen.)


    [macmoonshine]
    Ob "Marco"+" "+"Feltmann" eine sinnvolle Nutzung der Operatorenüberladung ist weiß ich nicht.
    Dass "Marco Feltmann"-" " keine sinnvolle Nutzung der Operatorenüberladung sein kann ist gewiss.

    Allerdings machst Du hier genau das, was ich anderweitig schon angemeckert habe.
    Du verbindest Swift mit einem Objective-C Framework. Beide Konzepte sind unglaublich unterschiedlich. Beide Konzepte arbeiten nahezu gegensätzlich.
    Vermutlich (hoffentlich) wirst Du in Swift diese ganzen unsinnigen Typen einfach los sein und ein ganz normales Tupel übergeben:
    let Point = (rect.midX()+inRadius*sin(inAngle), rect.midY()+inRadius*cos(inAngle))

    Aber momentan wird halt noch versucht, die Objective-C Typen irgendwie von Swift aus bedienen zu können. Dass das alles Andere als reibungslos verläuft dürfte wohl offensichtlich sein.


    [Amin]

    Quellcode

    1. let dividend = 5;
    2. let divisor = 7;
    3. let quotient = dividend/divisor;
    4. let square = square(quotient);
    5. let squareRoot = sqrt(square);

    Gern geschehen.

    Nein, Du weißt immer noch nicht auf den ersten Blick, ob Du jetzt eine Ganzzahl erhältst oder nicht.
    Wenn Du das mit dem Operatorenoverloading konsequent durchziehst kann es Dir auch egal sein. Ansonsten hilft der Compiler.

    Du kannst an Hand der Namen Annahmen über den Zustand zum jeweiligen Zeitpunkt treffen.
    Du solltest wissen, dass die Division von Ganzzahlen meist zum Resultat einer Ganzzahl führt.
    Du solltest wissen, dass das Quadrat einer Ganzzahl generell in einer Ganzzahl mündet.

    Vor Allem siehst Du auf den ersten Blick, dass am Ende squareRoot ungefähr gleich quotient sein sollte.

    Ordentliche Methoden- und Variablennamen werden durch Swift nicht über Nacht abgeschafft.

    Wo ist also das Problem?

    Gegenbeispiel:

    Quellcode

    1. id a = @5;
    2. id b = @7;
    3. id c = @([a intValue]/[b intValue])
    4. id d = [self modify:c];
    5. id e = [self modify:d];

    Auch hier kannst Du keinerlei Annahmen darüber treffen, was jetzt was sein wird.

    Natürlich kann Objective-C keine Methodenüberladung im traditionellen Sinne. Das hindert den Entwickler aber nicht daran, eine 'convenient factory method' zu basteln, die ähnlich einer überladenen Methode agiert.

    Es bedarf ungefähr genau so viel Energie verständlichen Code zu schreiben wie ihn unverständlich zu verschleiern, insofern finde ich den Ausdruck 'kriminelle Energie' bei der Fabrizierung von Spaghetticode durchaus angebracht.
    «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
  • Ich verstehe das Problem ebenfalls nicht und verstehe darüber hinaus nicht, was es mit Type-Inference zu tun hat.

    Noch weniger verstehe ich allerdings, wie man bei einem beworbenen Feature argumentieren kann, man müsse es ja nicht nutzen.
    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"?
  • @marco

    Das Problem ist – im alleeeinfachsten Falle1 –, dass eine int-Version eine int-Division durchführen wird, während eine Float-Version eine Float-Division durchführen wird. Das heißt, dass das Ergebnis nicht in etwa gleich ist, bloß eben in einem schlecht sichtbaren Typen, sondern sogar "mathematisch gewollt" anders sein kann.

    Aber ich habe ja gar nicht von Operatoren angefangen. Das geht bei jedem Overloading. Eine Operation von etwas von X kann etwas inhaltlich anderes machen als eine Operation von etwas auf Y. Das heißt, dass mein Kontrollfluss vom Typen abhängt, was ja auch üblich ist. Bei jeder überschriebenen Methode ist das der Fall. Da hilft ja deshalb auch glücklicherweise Liskow.

    Hier ist es aber so, dass das versteckt wird. Und zwar ohne erkennbaren Vorteil, wenn man davon absieht, eine Sekretärin zu sein.

    Bei Objective-C gibt es ja extra das Schlüsselwort id. Ich sehe also, dass das "unbekannter Typ" ist. Ich werde also auf das Problem hingewiesen.

    Und ja, Leute, die einfach immer id hinschreiben (gibt es), halte ich auch für reichlich dämlich.
    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"?
  • Marco Feltmann schrieb:

    Ob "Marco"+" "+"Feltmann" eine sinnvolle Nutzung der Operatorenüberladung ist weiß ich nicht.

    Sinnvoll oder sinnlos ist gleichgültig, weil es in Swift ein Fakt ist. Die Programmierer werden es nutzen, weil es vorhanden (und scheinbar) einfach ist.

    Marco Feltmann schrieb:

    Du verbindest Swift mit einem Objective-C Framework. Beide Konzepte sind unglaublich unterschiedlich. Beide Konzepte arbeiten nahezu gegensätzlich.

    Was soll ich denn auf einem iPhone sonst machen? Wenn schon Swift, dann doch bitte wenigstens Cocoa. ;) :D

    Marco Feltmann schrieb:

    Vermutlich (hoffentlich) wirst Du in Swift diese ganzen unsinnigen Typen einfach los sein und ein ganz normales Tupel übergeben:
    let Point = (rect.midX()+inRadius*sin(inAngle), rect.midY()+inRadius*cos(inAngle))

    Aber momentan wird halt noch versucht, die Objective-C Typen irgendwie von Swift aus bedienen zu können. Dass das alles Andere als reibungslos verläuft dürfte wohl offensichtlich sein.

    Das ist sie wieder: Die unrealistische Hoffnung auf den Erlöser. ;)

    Das casten lässt sich in meinem – und übrigens auch in Deinem – Beispiel nur vermeiden, wenn Apple in Swift
    1. CGFloat durch Double ersetzt,
    2. CGFloat-Versionen der mathematischen Funktionen anbietet, oder
    3. Du selber diese Funktionen schreibst.
    Das ist ein grundsätzliches Problem der Sprache und hat nichts mit Cocoa zu tun.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    SteveJ schrieb:

    Und jetzt?
    Wo liegt das Problem?


    Clang erwartet einen NSPoint als Rückgabewert von currentPoint (weil nur die Deklaration von NSBezierPath sichtbar ist). Der Code kompiliert so nicht,

    Quellcode

    1. CGPoint result = [[values objectAtIndex:0] currentPoint];
    2. NSLog(@"Value: %@", NSStringFromPoint(result));


    kompiliert, gibt aber (natürlich) falsche Ergebnisse. Clang macht auch eine Form der Type Interference, weil der Compiler wissen muss ob die Methode ein Objekt oder eine Struktur zurückgibt.

    Marco Feltmann schrieb:

    Ich übersetze Dein Gestammel mal in Laufzeitkram.


    Leider zeigt sich, dass Du nicht verstehst wovon du redest. Klar, Code ist für Laien immer „Gestammel“.

    Marco Feltmann schrieb:

    Denn was Du bekommst ist hier ganz eindeutig und reproduzierbar beim ersten und jeden weiteren Start der Anwendung:
    [TestClass] does not respond to selector -objectAtIndex:


    Bevor man Unsinn schreibt, einfach mal den Compiler anwerfen. Oder frei nach Nuhr verfahren.

    Amin Negm-Awad schrieb:

    Noch weniger verstehe ich allerdings, wie man bei einem beworbenen Feature argumentieren kann, man müsse es ja nicht nutzen.


    Wenn du in der Situation bist, das durch Type Interference der Code im Zusammenhang mit überschriebenen Funktionen unübersichtlich wird, spezifizierst du die Typen eben. Genau wie du nicht immer den Vorrang der Operatoren nutzt, sondern manchmal explizit klammerst, obwohl es nicht nötig ist - der Code wird leichter lesbar. Du klammerst aber auch nicht immer, das macht den Code wiederum schwer lesbar.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von SteveJ ()

  • SteveJ schrieb:


    Bevor man Unsinn schreibt, einfach mal den Compiler anwerfen. Oder frei nach Nuhr verfahren.

    Die Grundaussage bleibt erhalten:

    Du baust Mist und willst es der Programmiersprache ankreiden.
    «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

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Marco Feltmann ()

  • SteveJ schrieb:

    Clang macht auch eine Form der Type Interference, weil der Compiler wissen muss ob die Methode ein Objekt oder eine Struktur zurückgibt.

    Nein, das ist eben keine Type-Inference; das Programm kopiert stumpf sizeof(NSPoint) Bytes. Hier liegt eindeutig ein Fehler des Programmierenden vor. Der Fehler beginnt dabei bereits dabei, eine Methode zu verwenden, die nicht öffentlich deklariert wurde.
    „Meine Komplikation hatte eine Komplikation.“
  • Marco Feltmann schrieb:


    Die Grundaussage bleibt erhalten:

    Du baust Mist und willst es der Programmiersprache ankreiden.


    Große Worte für jemanden der viel Unsinn erzählt. Wo ist das Programm Mist?

    macmoonshine schrieb:

    SteveJ schrieb:

    das Programm kopiert stumpf sizeof(NSPoint) Bytes.


    Klar. Aber wie kommt Objective-C auf diese Idee?

    “Type inference is the ability to automatically deduce, either partially or fully, the type of an expression at compile time.”

    macmoonshine schrieb:

    Der Fehler beginnt dabei bereits dabei, eine Methode zu verwenden, die nicht öffentlich deklariert wurde.


    Wieso? Ich kann jede Methode an jedes Objekt schicken, das ist erst mal erlaubt, ist ja eine dynamische Sprache. Ich kann gerne vorher respondsToSelector: aufrufen, wenn es dich beruhigt.

    Wenn ich

    Quellcode

    1. @interface TestClass : NSObject
    2. - (int)currentPoint;
    3. @end

    in den Header packen, dann geht Clang plötzlich nicht mehr von einem (falschen) Rückgabewert aus, sondern gibt eine Fehlermeldung aus. Mit dem zusätzlichen Problem, dass Zugriffe auf Arrays die NSBezierPath-Elemente enthalten jetzt auch nicht mehr kompilieren, obwohl das vorher ging.

    Ich sage nicht, dass das unbedingt eine gute Idee ist. Nur kannst Du in Objective-C mit Typen auch seltsame Sachen machen und undurchschaubare Fehler produzieren.