Tschuligung, aber die Sache mit der statischen Typisierung wird immer absurder (adcdownload.apple.com/Develope…_for_Xcode_8_beta_4.pdf):
+rofl+
+rofl+
„Meine Komplikation hatte eine Komplikation.“
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.
macmoonshine schrieb:
Aber wieso nicht auch
[Foo conformsToProtocolOrMaybeNot:@protocol(BarProtocol)]
? 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.^^
macmoonshine schrieb:
let b = value as? A | B | C
t-no schrieb:
Das zeigt schonmal, dass der Sinn hinter "A & B & C" intuitiv verständlich ist;
b
? macmoonshine schrieb:
Welchen Typ hat denn nunb
?
b
vom gleichen Typ wie value
– welcher auch immer das sein mag. Und weil es ein Optional-Konstrukt ist, eben ein Optional davon. var foo: A & B
? Oo torquato schrieb:
Interessanter ist eigentlich die Frage: Welchen Typ hat var foo: A & B? Oo
A & B
. Der Variablen foo
kann alles zugewiesen werden, was die Protokolle A
und B
implementiert hat. macmoonshine schrieb:
Nein, gerade in einer statischen Programmiersprache ist das sehr seltsam. Welchen Typ hat denn nunt-no schrieb:
Das zeigt schonmal, dass der Sinn hinter "A & B & C" intuitiv verständlich ist;
b
?
t-no schrieb:
Ist das eine rhetorische Frage?
t-no schrieb:
"Float | Double" wäre eine Fließkommazahl
t-no schrieb:
"UIViewController & UITableViewDatasource" ist ein Viewcontroller, der zusätzlich Daten für einen TableView bereithält...
let x: protocol<A, B, C> = something
ein let x: A & B & C = something
halte ich für völlig dämlich.zwo
ist also vom Typ A. Und B. Und C. Und AB. Und AC. Und BC. Und ABC. Argh.kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
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.
Markus Müller schrieb:
Wenn Apple doch nur 1% der Swift Ressourcen in das Refactoring stecken würde...
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.
Fortrackz schrieb:
Ist eine Programmiersprache bei der man ständig rätseln muss was welchen Typ hat nicht kompletter Bullshit?
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.
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.
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. macmoonshine schrieb:
... und haut ihm aber bei Fehlern in die Fresse, wie eine statische Programmiersprache.
Marco Feltmann schrieb:
Ich kann ja den Beweggrund hinter diesem Proposal irgendwo nachvollziehen, aber stattlet x: protocol<A, B, C> = something
einlet 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'
&
: 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.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.
&
verwenden muß extension Array where Element: A & B {}
und einmal Kommata struct Bar: A, B {}
.