Objective C Fragen

[tjp]

Nein, mir sagen upcast und downcast tatsächlich nichts.

Ich denke Du solltest Dich mal mit dem Themenkomplex schwache Typisierung in Relation zur starken Typisierung auseinandersetzen. Dann wird auch klar, warum Up- und Downcast notwendig sind bzw. wo deren Vorteile liegen.

Vielleicht sehe ich etwas falsch, aber irgendwie glaube ich weiterhin, dass ich in Objective-C wunderbar z.B. das Programming By Contract Prinzip anwenden könnte, wenn ich das wollte.

Ich kenne das Konzept unter dem Begriff "Design by Contract". Objective-C ist eindeutig keine Programmiersprache mit ausgewiesenen DbC Unterstützung. Eiffel, D fallen mir da bei diesem Thema zuerst ein.

Allerdings werden spezielle Maßnahmen für DbC erst dann notwendig, wenn dynamische/schwache Typisierung involviert sind. In diesem Fall ist muß man die Garantien zur Laufzeit sicherstellen, die man mit starker Typisierung schon zum Übersetzungszeitpunkt sicherstellen konnte.

Dann kommen noch so Aspekte wie Effizienz ins Spiel. Das Methoden Dispatching (welche Methode muß konkret aufgerufen werden) unterscheidet sich ebenfalls maßgeblich. Objective-C verwendet dynamisches Dispatching, was zwar sehr flexibel ist, aber im Vergleich zum statischem Dispatching (Ada, C++) auch extrem langsam ist.

Das limitiert die Einsatzmöglichkeiten von Klassen in Objective-C drastisch. Man kann sie letztlich nicht dazu benutzen, daß man C structs + Funktionen zu einer Einheit zusammenfügt. Man muß hier weiterhin reines C programmieren.

Umgekehrt muß gibt es einige Probleme in C++ mit Patterns wie etwa Reflection, da muß man dann einen nicht unerheblichen Aufwand betreiben.

Ich habe nichts gegen dynamische Sprachelemente nur würde ich liebend gern auf sie verzichten, wenn sie beim Design überhaupt nicht benötigt werden. Das setzt dann aber eine Multiparadigmensprache voraus, die dann natürlich entsprechend kompliziert und umfangreich sein muß.

 

[commander]

Ups, ich wollte keine Codewars lostreten.

Ich erklär mich mal so: Da ich gewohnt bin, in großen Projekten zu arbeiten (50+ Entwickler) weiß ich, das Konventionen keinen Pfifferling wert sind. Solange man seinen Code selbst in der Hand hält, ist Qualität ja kein Problem, aber wehe, wenn Du ihn aus der Hand gibst - da passieren die unwahrscheinlichsten Sachen....

Deshalb nagel ich meinen Code idR total zu, um eine gewisse Sicherheit zu haben, dass sich alle Komponenten und Services wie erwartet verhalten. D.h., jeder, der mir ein Objekt übereichen will, muss das entsprechende Interface erfüllen (in ObjC ist das wohl ein Protokoll), jedes Objekt, das ich herausgebe, hat ebenfalls genau definierte Eigenschaften und Interfaces. Alle Parameter werden geklont, alle Klassen sind final, die nicht-Frameworkentwickler bekommen nur Proxies und Fassaden zu sehen, exzessives Exceptionhandling ist leider notwendig, denn nur das zwingt die Leute zum sauberen Arbeiten. Eine Abweichung von den definierten Standards ist nicht tolerierbar. Undokumentiere Funktionalität wird im Nightly Build bemeckert, Unit-Coverage ist oberste Pflicht, jeder Bug wird mit einem Test abgedeckt. Nur so kann man eine gewisse Ruhe in ein Projekt bringen trotz permanenter Weiterentwicklung. Und trotz dieser rigiden Vorgaben schaffen es einige Spezialisten, irgendwelche Schweinereien zu treiben (schlucken von Runtime-Exceptions z.B.), die die Qualität des gesamten Projekts gefährden.

Ich habe eigentlich gedacht, das ObjC ähnliche Mechanismen auf Sprachebene hat, aber so wie es auschaut, muss man das alles codeseitig erschlagen - nun gut, damit kann ich leben, solange ich alleine rumbastle. Dennoch kann ich mir vorstellen, wie hoch die Lernkurve für sauberes Entwickeln von umfangreicher Software mit vielen Entwicklern in ObjC ist.

Was genau fuerchtest Du denn fuer Gefahren von ins Nirvana gesendeten Botschaften à la [nil machWas]?

Nun, ich will z.B. schon aus der Doku den möglichen Wertebereich eines Rückgabewertes wissen - ist Null ausgeschlossen (z.B. Factory-Pattern), so gehe ich entsprechend vor und behandle das Objekt, ohne auf null zu prüfen. Sollte das Objekt jedoch trotzdem Null sein, so bekomme ich beim nächsten Zugriff korrekterweise eine NullPointerException - es liegt ja ganz offenbar ein Fehler vor.
Oder ich stecke was in eine HashMap, habe aber einen Fehler in der Berechnung des Hashcodes gemacht und kann das Objekt später nicht mehr finden.
In beiden Fällen empfinde ich es als wesentlich transparenter, wenn mir ein NullPointer um die Ohren fliegt, wenn ich vermeintlich ein Objekt in der Hand habe und manipulativ darauf zugreife, als dass meine Methodenaufrufe im Nirvana landen und das ganze evtl. erst viel später an anderer Stelle zu Fehlern führt....

Ja, Apple liebt Dich! Xcode bringt von sich aus Unit Test

Das ist schon mal sehr gut.

Und Coveragetools, die die Testabdeckung dokumentieren, ist das gleich mir dabei? Darüber kann ich in dem Dokument nichts finden....

 

[Peter Maurer]

[...] Da empfinde ich es als wesentlich transparenter, wenn mir ein NullPointer um die Ohren fliegt, als dass meine Methodenaufrufe im Nirvana landen und das ganze evtl. erst viel später an anderer Stelle zu Fehlern führt....

Verstehe. Und wie Du schon sagst -- das muss man dann bei Bedarf eben selber machen: NSAssert(samplePointer!=nil, @"Hi! I'm a surrogate NullPointerException.");

Und Coveragetools, die die Testabdeckung dokumentieren, ist das gleich mir dabei? Darüber kann ich in dem Dokument nichts finden....

Kann ich leider nicht sagen. Ich kenn' mich mit Unit Testing naemlich gar nicht aus -- im Gegensatz zu below, wie mir scheint.

 

[commander]

(...)NSAssert(samplePointer!=nil, @"Hi! I'm a surrogate NullPointerException.");

Jo, darauf läufts wohl raus. In meinem konkreten Falle ist das auch nicht wirklich schlimm.

btw: Weiß jemand, wie ich an die GUI-Elemente komme, die in der erweiterten Spotlight Ansicht kommen (losgelöster Dialog). Ich meine damit konkret die Suchkriterien, die man hinzufügen kann, also die Plus/Minusbuttons und die Comboboxen dazu.

Gruß,

.commander

 

[Peter Maurer]

Weiß jemand, wie ich an die GUI-Elemente komme, die in der erweiterten Spotlight Ansicht kommen (losgelöster Dialog). Ich meine damit konkret die Suchkriterien, die man hinzufügen kann, also die Plus/Minusbuttons und die Comboboxen dazu.

Der Carbon-Befehl, der dafuer eigentlich zustaendig sein sollte, naemlich HISearchWindowShow(), ist derzeit leider nur als Fragment zu bezeichnen, das die Festlegung von Kriterien (noch) nicht erlaubt.

Insofern fuerchte ich, Du wirst um GUI Scripting nicht herum kommen.

 

[below]

Kann ich leider nicht sagen. Ich kenn' mich mit Unit Testing naemlich gar nicht aus -- im Gegensatz zu below, wie mir scheint.

Ach, dieser Thread hat mir zu verstehen gegeben, dass ich besser den Mund halte bevor ich nicht weiss, was upcasts und downcasts sind.

Alex

 

[tjp]

Ach, dieser Thread hat mir zu verstehen gegeben, dass ich besser den Mund halte bevor ich nicht weiss, was upcasts und downcasts sind.

Das zeigt doch nur, daß Du bisher Programmiersprachen verwendest hast, in denen dieses Wissen nicht notwendig war. Meine Anmerkungen waren als Aufforderung gedacht, daß Du Dein Wissen erweiterst, und keine Auffoderung zum Schweigen. Allerdings wird es schwierig schwache und starke Typisierung zu diskutieren, wenn Du nicht beide Konzepte kennst.

SPARK (ein Subset von Ada) ist das Extrembeispiel für starke Typisierung, Sprache wie Tcl kennen gar keine Typen. Objective-C hat nur eine schwache Typisierung in einigen Situationen hat das Vor- in anderen Nachteilen. SmallTalk-80 kennt noch nicht einmal Protokolle, weil das ja eine Einfachvariante von Mehrfachvererbung ist, und die wollte man nicht haben. Statt dessen schickt man Messages, wenn der Name der Message und die Parameternamen übereinstimmen, dann versteht der Empfänger die Message. Der Empfänger muß zu keiner speziellen Klasse gehören.

Starke Typisierung sichert Eigenschaften von Kontrakten zu, so daß man vieles nicht umständlich im Programmcode hinschreiben muß sondern über Typen absichert. Dadurch können viel mehr Programmierfehler schon zum Übersetzungszeitpunkt erkannt werden. Man kann nicht alle Probleme erkennen, aber es sind eine Menge von potentiellen Fehlermöglichkeiten weg, der Preis dafür ist weniger Flexibilität und ein erhöhter Programmieraufwand, wenn man Patterns wie etwa Reflection umsetzen will. Wenn man keine Multiparadigmenprogrammsprache hat, die all diese Konzepte unterstützt, dann muß man sich für den einen oder anderen Weg entscheiden.

NeXT hatte damals Objective-C gewählt, weil es damals als die beste Lösung erschien. SUN hatte eine gewisse Zeit dieses Projekt unterstützt, dann aber recht schnell und konsequent auf Java gesetzt.

 

[commander]

So, mit den Sprachfeatures von ObjC und schwacher Typisierung kann ich mich inzwischen ganz gut anfreunden, ist anfänglich nur etwas ungewohnt.

KVC und KVO ist ja ziemlich cool, kenne das sonst nur von jsp. Aber: Da das ein Kernfeature von Cocoa ist und ich eine Menge Members in den Interfaces anlege, warum gibt mir XCode da nicht mehr Unterstützung - oder vielleicht: warum finde ich das entsprechende IDE Feature nicht, dass mir aus den Attribute im Interface gleich alle Accessoren erzeugt - ich muss die alle händisch einpflegen! Das ist ja Steinzeit!

Gibts dafür ein PlugIn oder bin ich blind....

Wie macht ihr das denn?

Gruß,

.commander

 

[commander]

Hat keiner einen Tip für mich?

Gibt doch sicher ein paar Codegeneratoren oder ähnliches für XCode.... habe bisher nur Accessorizer gefunden - aber das kostet. Vielleicht bin ich auch einfach zu blöd den InterfaceBuilder zu bedienen und dort verstecken sich am Ende irgendwelche Möglichkeiten, das direkt über die Bindings zu machen....

Den generischen Ansatz mit NSDictionary als Container für die Attribute find ich auch nicht soo elegant.

Gruß,

.commander

 

[MacApple]

warum finde ich das entsprechende IDE Feature nicht, dass mir aus den Attribute im Interface gleich alle Accessoren erzeugt

Keine Ahnung, warum Du das Feature nicht findest. Markiere im Interface die Instanzvariablen, für die Du Accessoren haben willst. Dann im Applescript-Menü (zwischen "Window" und "Help") den Punkt "Code->Place Accessor Decls on Clipboard" bzw. "Code->Place Accessor Defs on Clipboard" auswählen und das Ergebnis an entsprechender Stelle in den Code einfügen.

MacApple

 

[commander]

Keine Ahnung, warum Du das Feature nicht findest. Markiere im Interface die Instanzvariablen, für die Du Accessoren haben willst. Dann im Applescript-Menü (zwischen "Window" und "Help") den Punkt "Code->Place Accessor Decls on Clipboard" bzw. "Code->Place Accessor Defs on Clipboard" auswählen und das Ergebnis an entsprechender Stelle in den Code einfügen.

MacApple

Ok, ich habe diesen Menüpunkt ehrlich gesagt bisher übersehen .... - Danke!

Ausserdem kann man, wie ich inzwischen weiss, auch auss dem IB heraus Klassen generieren und muss sie nicht umgekehr erst schreiben und dann rübermoven.

Eins frage ich mich doch: ich hab inzwischen etliche Klassen, habe vorerst auf einen Namespace verzichtet - nun aber stell ich fest, dass ObjC überhaupt keine Namespaces kennt!

Wie strukturiert ihr denn Eure Klassenhierarchien, ohne dass man total den Überblick verliert - ich hab mal die etwas umfangreicheren ObjC Examples von Apple aufgemacht - nun gut, auch da kugeln dann so 100 Klassen alle unter 'Classes' herum, find ich nicht sehr übersichtlich...

Gibt es, ausser Prefixen, noch andere Möglichkleiten, die sich mir nicht direkt erschliessen?


Und noch eins: Ich versuche nun, ObjC mit Java zu verheiraten, erzeuge also eine Controller - Instanz in Java, stelle die entsprechenden Connections her und gebe die Actions an - so weit so gut, compiliert und alles wunderbar. Leider geht zur Laufzeit alles in die Hose, da das NIB die Klasse GoApoController nicht finden kann und benutzt NSObject - was natürlich nicht funzt....

Ich hab bereits den GoApoController wahlweise selbst implementiert, von NSController abgeleitet usw... es klappt einfach nicht. Muss ich irgendeine Abhängigkeit definieren, damit die Laufzeit aus dem NIB heraus auch die Javaklassen ansprechen kann? Schliesslich impliziert ja z.B. die Attributes Ansicht, dass man hier auch beliebige Java - Klassen verwenden kann.... und Apple lehnt sich mit der Cocoa-Java Bridge ja weit aus dem Fenster...


Gruß und schoma Danke,

.commander

 

[MacApple]

Ausserdem kann man, wie ich inzwischen weiss, auch auss dem IB heraus Klassen generieren und muss sie nicht umgekehr erst schreiben und dann rübermoven.

Ich dachte, das wäre schon bekannt, sonst hätte ich Dir den Tipp auch gleich gegeben.

Gibt es, ausser Prefixen, noch andere Möglichkleiten, die sich mir nicht direkt erschliessen?

Du kannst dir Deine Klassenhierarchie grafisch aufbereiten lassen. Markiere die Headerdateien, die Du mit in der Darstellung haben willst und dann im Menü "Design->Class Model->Quick Model" auswählen.

Und noch eins: Ich versuche nun, ObjC mit Java zu verheiraten, erzeuge also eine Controller - Instanz in Java, stelle die entsprechenden Connections her und gebe die Actions an - so weit so gut, compiliert und alles wunderbar. Leider geht zur Laufzeit alles in die Hose, da das NIB die Klasse GoApoController nicht finden kann und benutzt NSObject - was natürlich nicht funzt....

Ich habe so etwas zwar noch nie gemacht, aber ganz so einfach dürfte das auch nicht gehen. Vielleicht hilft Dir ja dieses Dokument weiter.

Schliesslich impliziert ja z.B. die Attributes Ansicht, dass man hier auch beliebige Java - Klassen verwenden kann.... und Apple lehnt sich mit der Cocoa-Java Bridge ja weit aus dem Fenster...

Na ja, nur wegen so einem kleinem Button davon auszugehen, dass man Objectiv-C und Java-Klassen einfach so mischen kann, ist doch etwas naiv. Da sollte man sich schon erst einmal ein bisschen in der Dokumentation umschauen, bevor man anfängt zu meckern.

Übrigens wird die Cocoa-Java Bridge von Apple nicht mehr weiter gepflegt. Neue Cocoa Features bleiben für Java ausgeschlossen.

MacApple

 

[commander]

I
Na ja, nur wegen so einem kleinem Button davon auszugehen, dass man Objectiv-C und Java-Klassen einfach so mischen kann, ist doch etwas naiv. Da sollte man sich schon erst einmal ein bisschen in der Dokumentation umschauen, bevor man anfängt zu meckern.

Dokumentation lesen war so ziemlich meine Hauptbeschäftigung die letzten 10 Tage abends.... Ich besitze ein RTFM T-Shirt - nur so nebenbei

Und dass das Mischen an und für sich funktioniert, zeigen ja die Developer Examples ausführlich... somit sollte es mit einem generischen Ansatz auch möglich sein, über Reflection (als Selectorersatz) beliebige Java-Objekte einzubinden, genau das leistet ja die Bridge.

Dennoch scheint mir etwas Wesentliches entgangen zu sein, denn das das Binding der Klassen funktioniert nicht so, wie ich mir das denke. Ich bin mir nicht im Klaren darüber, wie der Klassenpfad der Javaklassen für die Laufzeit verfügbar wird, die Java Klassen bleiben für die ObjC Schicht unsichtbar ... Ich dachte bisher, die NIBs bringen sowas wie einen dynamischen Proxy mit, über den die Bridge bedient wird ... sollte es etwa so sein, dass ich die jobs und ObjC Klassen selbst erstellen muss?

Dagegen spricht, dass auch die Apple Beispiele nur NIBs und Javaklassen verwenden.... allerdings funzen die bei mir ebenfalls nicht out of the box.

Könnte sein, dass sich mit Tiger da irgendwas geändert hat. Aber selbst wenn ich die Kompatibilität auf 10.2 stelle, ändert das nichts.

Dass die neuen Cocoa Features für Java nicht zur Verfügung stehen, ist mir klar, macht aber nichts, erstens langt mir das, was ich habe (falls es denn endlich funktionieren würde), und zweitens bin ich mit dem JavaNativeInterface vertraut und kann mir sowas gut selbst basteln, wenn ichs denn unbedingt brauche.

Trotzdem vielen Dank für die Mühe!

Gruß,

.commander

 

[MacApple]

Dokumentation lesen war so ziemlich meine Hauptbeschäftigung die letzten 10 Tage abends.... Ich besitze ein RTFM T-Shirt - nur so nebenbei

Na, dann will ich nichts gesagt haben. Aber warum sich Apple da jetzt weit aus dem Fenster legt, verstehe ich trotzdem nicht.

Und dass das Mischen an und für sich funktioniert, zeigen ja die Developer Examples ausführlich... somit sollte es mit einem generischen Ansatz auch möglich sein, über Reflection (als Selectorersatz) beliebige Java-Objekte einzubinden, genau das leistet ja die Bridge.

Dennoch scheint mir etwas Wesentliches entgangen zu sein, denn das das Binding der Klassen funktioniert nicht so, wie ich mir das denke. Ich bin mir nicht im Klaren darüber, wie der Klassenpfad der Javaklassen für die Laufzeit verfügbar wird, die Java Klassen bleiben für die ObjC Schicht unsichtbar ... Ich dachte bisher, die NIBs bringen sowas wie einen dynamischen Proxy mit, über den die Bridge bedient wird ... sollte es etwa so sein, dass ich die jobs und ObjC Klassen selbst erstellen muss?

Wie gesagt, mit Java und Cocoa habe ich noch nichts zu tun gehabt. Nur ich stelle mir das so vor, dass in einem Nib ja keine Objektive-C oder Java-Objekte gespeichert sind. Das sind ja archivierte Objekte ohne Code und je nachdem von "welcher Sprache" ausgehend so ein Nib geladen wird, entsteht dann im Speicher eine Java oder Objective-C Instanz. Wenn man dann also von Objective-C aus so ein Nib läd und da drin ist eine Instanz, für die nur Java-Code vorliegt, dann machts halt bumm. Das kann natürlich auch alles Blödsinn sein, was ich mir diesbezüglich zusammenreime.

MacApple