Swift

  • markusschalk schrieb:

    Mit dem DataHiding Principle nimmt man es bei Apple mit Swift auch nicht so genau..

    Das kann man in vielen Sprachen, inklusive Objective-C, sowieso umgehen. Data-Hiding ist ein Design-Prinzip, das in erster Linie die Programmierer befolgen sollten. Schutzmechanismen in der Programmiersprache sind da häufig nur syntaktischer Zucker. Wie gut ein Programmierer dieses Prinzip verinnerlicht hat, sieht man in der Regel daran, inwieweit er sich bei seinen eigenen Klassen daran hält.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    markusschalk schrieb:

    Mit dem DataHiding Principle nimmt man es bei Apple mit Swift auch nicht so genau..

    Das kann man in vielen Sprachen, inklusive Objective-C, sowieso umgehen. Data-Hiding ist ein Design-Prinzip, das in erster Linie die Programmierer befolgen sollten. Schutzmechanismen in der Programmiersprache sind da häufig nur syntaktischer Zucker. Wie gut ein Programmierer dieses Prinzip verinnerlicht hat, sieht man in der Regel daran, inwieweit er sich bei seinen eigenen Klassen daran hält.

    Das ist mir bewusst. Solange man alleine an einem Projekt arbeitet, sehe ich darin kein Problem.

  • markusschalk schrieb:

    Solange man alleine an einem Projekt arbeitet, sehe ich darin kein Problem.

    Auch bei mehreren Leuten ist das kein Problem, wenn sie Data-Hiding verinnerlicht haben.

    Beispielsweise verstecken viele Java-Projekte vollkommen willkürlich und unnötig Methoden, die sich sehr gut für Erweiterungen eignen. Oder der Zugriff auf Attribute ist öffentlich oder geschützt, igitt. Wenn das Prinzip nicht verstanden wurde, helfen Sprachkonstrukte auch nicht weiter.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    markusschalk schrieb:

    Solange man alleine an einem Projekt arbeitet, sehe ich darin kein Problem.

    Auch bei mehreren Leuten ist das kein Problem, wenn sie Data-Hiding verinnerlicht haben.

    Beispielsweise verstecken viele Java-Projekte vollkommen willkürlich und unnötig Methoden, die sich sehr gut für Erweiterungen eignen. Oder der Zugriff auf Attribute ist öffentlich oder geschützt, igitt. Wenn das Prinzip nicht verstanden wurde, helfen Sprachkonstrukte auch nicht weiter.



    Da stimme ich dir voll und ganz zu.

  • Amin Negm-Awad schrieb:

    Und was ist der Unterschied zwischen Compile-Time-Fehler und Laufzeitfehler während der Entwicklung? 2 Minuten? Du wirst mehr Zeit mit der "Bearbeitung" von Templates verbracht haben.

    Ich schrieb nicht umsonst "in production". Ob ich den Fehler nach einem cmd-R ein paar Sekunden später erhalte, ist mir so etwas von gleichgültig.

    In der Theorie spreche ich Dir einen guten Punkt zu. Leider hat man aber in der Praxis nicht immer 100% Testabdeckung, Entwickler vergessen Tests, oder automatische Tests sind in manchen Fällen gar nicht praktikabel. Wenn man sich dann auch noch einen Crash / Laufzeitfehler nicht erlauben darf, ist man froh, wenn der Compiler sich zumindest um ein Teil kümmert.

    Ich gebe Dir auch gerne Recht, dass Templates jetzt nicht für Jedermann intuitiv und schnell zu benutzen sind. Aber mit ein wenig Erfahrung würde ich, zumindest von mir selbst, behaupten, dass ich Templates schreibe und benutze, ohne dabei unnötig Zeit zu verlieren oder mein Hirn übermässig anstrengen zu müssen.
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Und was ist der Unterschied zwischen Compile-Time-Fehler und Laufzeitfehler während der Entwicklung? 2 Minuten? Du wirst mehr Zeit mit der "Bearbeitung" von Templates verbracht haben.

    Ich schrieb nicht umsonst "in production". Ob ich den Fehler nach einem cmd-R ein paar Sekunden später erhalte, ist mir so etwas von gleichgültig.

    In der Theorie spreche ich Dir einen guten Punkt zu. Leider hat man aber in der Praxis nicht immer 100% Testabdeckung, Entwickler vergessen Tests, oder automatische Tests sind in manchen Fällen gar nicht praktikabel. Wenn man sich dann auch noch einen Crash / Laufzeitfehler nicht erlauben darf, ist man froh, wenn der Compiler sich zumindest um ein Teil kümmert.

    Ich gebe Dir auch gerne Recht, dass Templates jetzt nicht für Jedermann intuitiv und schnell zu benutzen sind. Aber mit ein wenig Erfahrung würde ich, zumindest von mir selbst, behaupten, dass ich Templates schreibe und benutze, ohne dabei unnötig Zeit zu verlieren oder mein Hirn übermässig anstrengen zu müssen.
    Gerade von einem praktischen Standpunkt aus schaue, ergibt sich für mich kein Vorteil. Es gibt diese angeblichen Gefahren der "Typunsicherheit" gar nicht. Sie tauchen einfach nicht auf. Ich weiß, dass Typsicherheit theoretisch besser ist, das gebe ich dir gerne zu. Nur wieso soll ich mich vor einer theoretischen Gefahr schützen, wenn sie sich praktisch nicht aktualisiert?

    Womit ich elegant zum Zweiten Teil überkleidet hätte. :-]

    Klar, ich gebe dir auch zu, dass du das um Meilen besser hinbekommst als ich. Aber erst einmal musstest du das ja lernen, Erfahrungen sammeln, kryptische Fehlermeldungen, die nur verständlich sind, wenn man das Template "im Kopf selbst instanziert", verstehen usw.

    Es bleibt eine Abwägungsfrage, klar. Es ist nicht so, dass das eine nur Vorzüge, das andere nur Nachteile hätte. Klar. Aber es kommt mir ein bisschen so form, als ob ich in einer Höhle unter einem Wasserfall einen Rauchmelder an der Decke installiere – und dabei von der Leiter falle.
    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"?

  • apple877 schrieb:

    Ja das stimmt schon aber ich find diese Syntax so unaufgeräumt von Swift ohne klammern wo meiner Meinung nach der Schönheit halber einfach eine hingehört, ohne semikolon und ohne header. Ich mag das mittlerweile gar nicht mehr alles in eine Datei zu schreiben das wirkt dann alles so überfüllt und das gefällt mir einfach irgendwie nicht so ganz :/


    Das gleiche könnte man über Deine Orthographie sagen. In dem Zusammenhang verstehe ich Dein Problem mit Swift nicht.

  • markusschalk schrieb:

    Nur bei Swift ist das halt durch das frühe Entwicklungsstadium alles noch nicht so toll dokumentiert.
    Es geht nicht um toll dokumentiert. Man kann über jedes Features etwas Gutes sagen. Und das würde dann sogar stimmen. Das Problem taucht auf, wenn sich das kombiniert:

    Inferred-Types? Schöne Sache.

    Generics? Schöne Sache.

    Welche Regeln gelten aber bei der Kombination von Inferred-Types (der Compiler schließt einen Typen aus dem Sourcecode) und Generics (der Typ bleibt unbesetzt und wird erst zur Übersetzungszeit instantiert)? Hat das wirklich schon jeder geblickt? Lattner?

    Bei C++ sind jetzt, Jahre nach der Entwicklung und der Erfindung von Generics, Concepts hinzugekommen, weil eben es Ewigkeiten gedauert hat, das Problem zu erkennen, zu verstehen, zu lösen. Lattner hat das AFAIK bereits in Swift eingebaut. Das soll nur als Beispiel dienen, dass die Auswirkungen solcher Features nur schwer vorhersehbar sind. Für sich allein genommen und erst Recht in der Kombination. Und wenn du dann am ende dahin kommst, dass die ganze Angelegenheit so kompliziert ist, dass man für jede Klasse besser erst einmal eine Factory-Klasse schreibst, dass du Anytype-Hilfsklassen brauchst usw. usf., dann ist die versprochene schöne Einfachheit nur noch Aufwand.
    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:

    Gerade von einem praktischen Standpunkt aus schaue, ergibt sich für mich kein Vorteil. Es gibt diese angeblichen Gefahren der "Typunsicherheit" gar nicht. Sie tauchen einfach nicht auf. Ich weiß, dass Typsicherheit theoretisch besser ist, das gebe ich dir gerne zu. Nur wieso soll ich mich vor einer theoretischen Gefahr schützen, wenn sie sich praktisch nicht aktualisiert?

    Womit ich elegant zum Zweiten Teil überkleidet hätte. :-]

    Klar, ich gebe dir auch zu, dass du das um Meilen besser hinbekommst als ich. Aber erst einmal musstest du das ja lernen, Erfahrungen sammeln, kryptische Fehlermeldungen, die nur verständlich sind, wenn man das Template "im Kopf selbst instanziert", verstehen usw.

    Es bleibt eine Abwägungsfrage, klar. Es ist nicht so, dass das eine nur Vorzüge, das andere nur Nachteile hätte. Klar. Aber es kommt mir ein bisschen so form, als ob ich in einer Höhle unter einem Wasserfall einen Rauchmelder an der Decke installiere – und dabei von der Leiter falle.

    Wenn in der Höhle unter dem Wasserfall ein Atomreaktor steht, ja, dann installier ich vielleicht auch recht gern Rauchmelder :)
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Gerade von einem praktischen Standpunkt aus schaue, ergibt sich für mich kein Vorteil. Es gibt diese angeblichen Gefahren der "Typunsicherheit" gar nicht. Sie tauchen einfach nicht auf. Ich weiß, dass Typsicherheit theoretisch besser ist, das gebe ich dir gerne zu. Nur wieso soll ich mich vor einer theoretischen Gefahr schützen, wenn sie sich praktisch nicht aktualisiert?

    Womit ich elegant zum Zweiten Teil überkleidet hätte. :-]

    Klar, ich gebe dir auch zu, dass du das um Meilen besser hinbekommst als ich. Aber erst einmal musstest du das ja lernen, Erfahrungen sammeln, kryptische Fehlermeldungen, die nur verständlich sind, wenn man das Template "im Kopf selbst instanziert", verstehen usw.

    Es bleibt eine Abwägungsfrage, klar. Es ist nicht so, dass das eine nur Vorzüge, das andere nur Nachteile hätte. Klar. Aber es kommt mir ein bisschen so form, als ob ich in einer Höhle unter einem Wasserfall einen Rauchmelder an der Decke installiere – und dabei von der Leiter falle.

    Wenn in der Höhle unter dem Wasserfall ein Atomreaktor steht, ja, dann installier ich vielleicht auch recht gern Rauchmelder :)


    Wenn der Reaktor schon raucht nutzt die der Melder auch nicht mehr :P

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Gerade von einem praktischen Standpunkt aus schaue, ergibt sich für mich kein Vorteil. Es gibt diese angeblichen Gefahren der "Typunsicherheit" gar nicht. Sie tauchen einfach nicht auf. Ich weiß, dass Typsicherheit theoretisch besser ist, das gebe ich dir gerne zu. Nur wieso soll ich mich vor einer theoretischen Gefahr schützen, wenn sie sich praktisch nicht aktualisiert?

    Womit ich elegant zum Zweiten Teil überkleidet hätte. :-]

    Klar, ich gebe dir auch zu, dass du das um Meilen besser hinbekommst als ich. Aber erst einmal musstest du das ja lernen, Erfahrungen sammeln, kryptische Fehlermeldungen, die nur verständlich sind, wenn man das Template "im Kopf selbst instanziert", verstehen usw.

    Es bleibt eine Abwägungsfrage, klar. Es ist nicht so, dass das eine nur Vorzüge, das andere nur Nachteile hätte. Klar. Aber es kommt mir ein bisschen so form, als ob ich in einer Höhle unter einem Wasserfall einen Rauchmelder an der Decke installiere – und dabei von der Leiter falle.

    Wenn in der Höhle unter dem Wasserfall ein Atomreaktor steht, ja, dann installier ich vielleicht auch recht gern Rauchmelder :)
    Da steht aber keiner.

    Aber ich hatte gestern längere Tweets mit einem Typen. Heute hat er es mal ausprobiert:

    twitter.com/planetexpress69/st…74563287670337538/photo/1

    Ach, das ist ja so toll mit dem Operatoroverlaoding. Keiner braucht es, aber es erzeugt einen Haufen inkonsistenter Scheiße.

    @kmr Nicht relevant? Machen wir eine Wette, wann es das erste mal auftaucht?
    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:


    Erinnert so ein bisschen an den WAT Lightning Talk. Naja, lieber einen Fehler als NaN. ;)
    «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

  • Amin Negm-Awad schrieb:


    @kmr Nicht relevant? Machen wir eine Wette, wann es das erste mal auftaucht?


    Ich kann ja nur für die Apps sprechen, deren Sourcecode ich in die Finger kriege. Und da sind die von Euch erwähnten Probleme wirklich nur rein akademischer Natur. Wer Base64 für eine Verschlüsselung hält, wer AES verwendet, aber das Passwort als String im Binary kodiert, wer die Keychain verwendet, dass Passwort aber nicht ins Feld kSecValue, sondern in das Feld für den Service-Label schreibt, und wer mit Singletons hantiert, weil er das von Java nun mal so kennt, für den macht es keinen Unterschied, ob er Swift oder Objc in den Fingern hat. Furchtbar ist das Ergebnis allemale. ^^