Benutzerdefinierte Bottom Bar

Kann ich zu hause (.4) nicht starten. Mutmaßlich willst du darauf hinaus, dass man in seiner Source die Klasse abfragen kann. Was das allerdings mit dem Laufzeitsystem zu zu tun hat …?
Hier ist ein Code, der das Gegenteil beweist:
Aber frag mich nicht, was das mit dem Laufzeitsystem zu tun hat …

Aber den Source müsstest Du Dir auch unter .4 ansehen können. Im xib passiert nicht viel.

Der kommt direkt aus dem AppKit. Sprich: Du kannst einem Fenster nichts unterschieben, was nicht von NSView abgeleitet ist. Auch wenn Du alles von NSResponder und NSView implementierst. qed.

Original von mattik
Aber den Source müsstest Du Dir auch unter .4 ansehen können. Im xib passiert nicht viel.

Quellcode

1. 2008-05-23 21:51:40.906 MyFakeViewText[9108:10b] *** Assertion failure in -[NSThemeFrame addSubview:], /SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:1809
2. 2008-05-23 21:51:40.908 MyFakeViewText[9108:10b] Invalid parameter not satisfying: [aView isKindOfClass:[NSView class]]

Der kommt direkt aus dem AppKit. Sprich: Du kannst einem Fenster nichts unterschieben, was nicht von NSView abgeleitet ist. Auch wenn Du alles von NSResponder und NSView implementierst. qed.

Das ahnte ich ja auch. Also noch einmal: Was hat das mit dem Laufzeitsystem zu tun? Oder zählst du AppKit zum Laufzeitsystem?

Oder der Dynamik des Laufzeitsystems? Das scheint irgendwie ein Laufzeittest zu sein. Nicht dynamisch? Ich habe das so gelernt, dass man vom dynamischen Typing spricht, wenn der Test zur Laufzeit erfolgt. Und was geschieht hier …?

Du hast also gerade bewiesen, dass man in etwas anderem als dem Laufzeitsystem statisch programmieren kann. Das hatte aber nun gar nichts mit meiner Behauptung zu tun.

Hier ist übrigens gleich noch ein Beleg für deine Behauptung:

Ich muss noch was machen …

Original von Tom9811
Ja, und ein View, welches eine ActionCell besitzt und das Action-Target-Muster implementiert, ist ein Control.

Das Beispiel zeigt, dass ein Objekt, das View-Mechanismen implementiert, kein View ist. Analog dazu ist ein View, das Control-Mechanismen implementiert, kein Control. Ich sehe, dass Du es nicht verstehen, einsehen oder zugeben willst. Auch gut.

Original von mattik

Original von Tom9811
Ja, und ein View, welches eine ActionCell besitzt und das Action-Target-Muster implementiert, ist ein Control.

Das Beispiel zeigt, dass ein Objekt, das View-Mechanismen implementiert, kein View ist. Analog dazu ist ein View, das Control-Mechanismen implementiert, kein Control. Ich sehe, dass Du es nicht verstehen, einsehen oder zugeben willst. Auch gut.

Nein, es zeigt, dass jemand die Klasse positiv abfragt. Mit dem Laufzeitsystem hat das nichts zu tun. Warte, ich suche noch einmal meine Behauptung heraus:

Für das gesamte Laufzeitsystem kommt es für die Typisierung ausnahmslos auf das Können an. Ich habe noch nie erlebt, dass das Laufzeitsystem von sich aus fragt, was denn die Klasse ist.

Deine Antwort darauf:

Objective-C hat Elemente dynamischer Typisierung, aber es ist keine vollständig dynamisch typisierte Sprache. Dass Du das noch nicht erlebt hast, ändert das nicht.

Da ist einiges bemerkenswert:
a) Die Frage nach Können vs. Sein hat nichts mit Dynamik zu tun. Beide Fragestellungen (Klasse bzw. Können) können dynamisch oder statisch beantowrtet werden. Aber gut, darüber bin ich hinweggegangen, weil verständlich war, worauf du eigentlich hinaus wolltest, auch wenn die Begrifflichkeit misslang. Aber Begriffe sind ohnehin Schall und Rauch. Auf die Ideen kommt es an.
b) "Objective-C hat Elemente dynamischer Typisierung …" Nein Objective-C typisiert mit Ausnahme von super ausschließlich dynamisch. Dein Beispiel ist eine Abfrage aus einerr Source des AppKits heraus. Das hat nichts mit Objective-C zu tun und nichts mit dem Laufzeitsystem. Das ist so statisch, wie die "statische Variable" in meinem Codebeispiel. Daran kann man auch sehen, dass Objective-C Variablenwerte statisch behandelt. War wirklich einfach zu beweisen!

(c) Man stelle sich bloß vor, in der nächsten Version verlangt NSButtonCell noch eine weitere Methode, die NSButton implementiert. *Huch* Das ist ja viel wahrscheinlicher, als irgendwelche Klicks auf inaktive Buttons, die kein Target und keine Action haben und deshalb die statische Geisterbahnfahrt durchs Universum anfangen.)

Wichtiger: Aber dein Argument ist ja lustig: Du fakst ein Control, welches nicht die Klasse NSControl besitzt und bestehst auf diese Typisierung. Gleichzeitig würde genau bei Anwendung deiner Idee deine Lösung nicht funktionieren.

Schon irre, wie du gegen dich selbst argumentierst.

Aber "gut" ist richtig. Ich glaube auch nicht, dass das hier noch einen Lerneffekt hat, zumal einer von uns schon das Stadium des "Unliebsame Teile zitiere ich nicht" erreicht hat.