Private Methoden selber Basteln

Extensions bzw. Categories gibts schon immer. Neu in 2.0 sind anonyme Categories bzw. class continuations. Das "Konzept" wird ja nicht nur für "private" Methoden genutzt sondern auch für andere Dinge, die sehr sinnig sind.

Du kannst in den Build-einstellungen definieren, dass Warnungen vom Compiler wie Fehler behandelt werden: Dann kompiliert Xcode bei Warnungen nicht fertig.

Umgehen kannst du das dennoch, indem du eben diese "Runtime"-Tricks nutzt.

Original von johannesauer

Wenn an einem Stromkasten die Warnung hängt: 2Vorsicht Starkstrom" und jemand dennoch mit seinen Händchen reinpackt, nennst du das versehentlich?

Kannst du mir kurz mal Absicht definieren?

Ich fände es einfach schöner, wenn Methoden, genau wie Members, mit @protected zu kennzeichnen wären. Das wäre konsistent, und ein Error ist besser als ne Warnung.

Nein, wenn du über das Dispatching von die Dynamik von Objective-C nachdenkst, siehst du, dass es nicht konsistent wäre.

In C sind Warnungen und Fehler ohnehin ohne System verteilt. Das rste, was man machen sollte, ist -Werror (Treat Warnings as Errors).

Original von johannesauer Und warum das nicht so ist verstehe ich nicht.

Weil der Bau einer Nachricht nicht, aber auch rein gar nichts, mit dem Adressaten zu tun hat. Du kannst Nachrichten bauen, wie du willst, ohne dass du die Klasse des Empfängers kennst. Daher kann es denknotwendig nicht auf dessen Satz an Methoden ankommen.

Original von johannesauerSind Extensions eigentlich was neues in Obj-C 2.0? Mir kommt das Extensions Konzept eher wie ein Notbehelf vor...das ist alles.

Kategorien gab es schon immer. Sie sind auch kein Notbehelf, sondern ein Strukturierungsmerkmal. Das hat auch nicht mit Protected zu tun, da es haufenweise öffentliche Kategorien gibt.

AspectJ führt sie auch für Java ein.

Original von johannesauerInsgesamt kommt mir Obj-C und Cocoa sehr offen vor. Ich kenne mich mit den Konzepten nicht gut genug aus, und das IST sicher Teil des Konzeptes.

Ja, wobei es hier um das Konzept der Nachricht geht. Das war für Alay Kay zentral. Du wirst damit leben müssen, es jetzt mit einer richtigen oo-Sprache zu tun zu haben und nicht mit Sprachen, die das zwar für sich in Anspruch nehmen, dabei aber ziemlich die Wahrheit zurechtbiegen.

Original von johannesauerEin Beispiel ist z.B. KVC. Da muss man auch erst sagen, das man NICHT auf die Members zugreifen darf...aber wie gesagt, die Apple Jungs sind ja nicht doof, das hat sicher einen Sinn.

Das ist ziemlich doof, aber bequem. Es ist insoweit aber kein Problem, weil die entsprechenden Methoden selbst KVO-Nachrichten erzeugen, also dann doch so tun, als ob es über eine Methode erfolgt wäre. Es dürfte keinen merkbarenUnterschied geben, ob du einen synthetisierten Setter hast oder nicht. Und wenn du einen eigenen Setter programmiert hast, wird der ja auch benutzt und das Problem existiert gar nicht.

Original von johannesauer

Du meinst #pragma mark?

Funktioniert bei mir.

seltsam, bei mir macht der sowas:

Ist die Datei ohne Warnungen kompilierbar?

Original von Objcler
Extensions bzw. Categories gibts schon immer. Neu in 2.0 sind anonyme Categories bzw. class continuations. Das "Konzept" wird ja nicht nur für "private" Methoden genutzt sondern auch für andere Dinge, die sehr sinnig sind.

Du kannst in den Build-einstellungen definieren, dass Warnungen vom Compiler wie Fehler behandelt werden: Dann kompiliert Xcode bei Warnungen nicht fertig.

Umgehen kannst du das dennoch, indem du eben diese "Runtime"-Tricks nutzt.

Wobei ich das präzisieren möchte:

Es sind keine Tricks und es ist auch nicht die Runtime (die du ja auch in Anführungszeichen gesetzt hattest) dafür notwendig.

Objective-C kennt Klassen (mit Klassenobjekten), Instanzobjekte und Nachrichten. Nachrichten sind nicht kastrierte Vorstellungen wie in C++ oder Java, sondern ein eigenständige Gebilde. Sie sind unabhängig vom Empfänger. Solcher Code ist zulässig:
Nirgendwo ist hier eine Zielklasse versteckt. Daher kann es auch keinen Verweis auf die Methoden des Zieles geben, erst recht keinen Verweis, ob diese dann privat sind.

Dementsprechend kommt man ganz ohne das RTE aus, wenn man sich Nachrichten selbst zusammenbaut. Das geht mit SEl, @selector, NSSelectorFromString() usw. Nichts ist RTE.

Word!!!

Vielleicht hilft dir das Folgende: In C++/Java gehört eine Methode immer genau zu einer Klasse (oder zu mehreren Klassen, die dann aber in einer ist-Beziehung stehen). In Objective-C gehört ein Selector ( = "Methode" (ja auch nicht ganz richtig - aber aus pädagogischen Gründen) zu KEINER Klasse.

Original von johannesauer

Ist die Datei ohne Warnungen kompilierbar?

ja ist sie. Hier die syntax:

#pragma mark blablabla

Die Syntax des Pragmas ist schon klar. Was soll man dabei falsch machen.

Zuweilen stolpert aber der Parser. Meist ist das der Fall, wenn sich das Ding auch nicht kompilieren lässt

Hast du ungewöhnliche Konstrukte verwendet? IIRC ist mir das mal bei einem \" in einem String aufgefallen. Damit kam der nicht zurecht.

Manchmal hilft es auch Xcode neu zu starten, weil der wohl cached und sich dabei etwas zerhaut. (Womit auch deine Frage zu Seitenefekten beantwortet wäre …)

developer.apple.com/mac/librar…/Reference/reference.html

Original von johannesauer
Gibt es denn Dokumentation über die Runtime? An sich mag ich Objective-C sehr gerne (auch wenn das hier vielleicht anders ankommt), aber ich würde gerne verstehen warum manche Dinge sind wie sie sind.

Gruss,
Johannes

Dazu musst du dich nicht in das RTE einlesen. Du musst einfach nur über Objective-C nachdenken. Wichtig ist hier eigentlich nur, dass du niemals, nicht, nie mehr, nimmer und bis an das Ende des Universums und noch drei Tage denkst, eine Nachricht habe etwas mit dem Adressaten zu tun.

Vielleicht hilft dir das ein bisschen:
macoun.de/?page_id=536

Original von johannesauer
aber ich würde gerne verstehen warum manche Dinge sind wie sie sind.

Du versuchst, dein C++ Wissen auf Objective-C zu übertragen.
Das funktioniert ähnlich gut wie der Versuch, dein Wissen über die Cessna 172 auf einen Eurofighter anzuwenden.

Zusätzlich zu Amins Hinweis:
macoun.de/?page_id=1532

Original von johannesauer

Du meinst #pragma mark?

Funktioniert bei mir.

seltsam, bei mir macht der sowas:

Das ist kein Fehler. Du hast in den Einstellungen unter Code Sense: Sort list alphabetically eingestellt. Dann lassen sich die Markierungen nicht mehr ordentlich in der Liste anzeigen.

Original von macmoonshine

Original von johannesauer

Du meinst #pragma mark?

Funktioniert bei mir.

seltsam, bei mir macht der sowas:

Das ist kein Fehler. Du hast in den Einstellungen unter Code Sense: Sort list alphabetically eingestellt. Dann lassen sich die Markierungen nicht mehr ordentlich in der Liste anzeigen.

Ach, das ist mir gar nicht aufgefallen.

Danke!

Original von Amin Negm-Awad
Die kann denn ohne Pimpl ein User versehentlich eine private Methode aufrufen?

Indem man sie im Header deklariert (was man ja eigentlich nicht tun sollte bzw. auch gar nicht braucht). Manchmal sind Prototypen ganz gut, und die alle am Anfang der Implementation zu haben ist auch nicht so schön oder?

Original von zermelo

Original von Amin Negm-Awad
Die kann denn ohne Pimpl ein User versehentlich eine private Methode aufrufen?

Indem man sie im Header deklariert (was man ja eigentlich nicht tun sollte bzw. auch gar nicht braucht). Manchmal sind Prototypen ganz gut, und die alle am Anfang der Implementation zu haben ist auch nicht so schön oder?

Dann sind sie nicht privat.

So gesehen kann man auch in C++ private Methoden aufrufen. Wenn man sie als public deklariert.

Man muss die auch nicht alle am Anfang der Implementierung haben. Man kann Bottom-Up strukturieren, auch wenn das Hillegass nicht tut.

Original von zermelo

Original von Amin Negm-Awad
Die kann denn ohne Pimpl ein User versehentlich eine private Methode aufrufen?

Indem man sie im Header deklariert (was man ja eigentlich nicht tun sollte bzw. auch gar nicht braucht). Manchmal sind Prototypen ganz gut, und die alle am Anfang der Implementation zu haben ist auch nicht so schön oder?

was haben PRIVATE methoden in einem prototyp zu suchen...?

Original von gritsch
was haben PRIVATE methoden in einem prototyp zu suchen...?

Sorry, ich weiss nicht, wie man das in Objective-C nennt. Ein Prototyp ist in C/C++ eine Vorab-Deklaration einer Methode.
Ich weiss gar nicht, wie man soetwas in Objective-C macht, ganz so einfach scheint das nicht.
Nimm folgendes Beispiel und stell Dir vor, beide Methoden sollen privat sein:

Da beide voneinander abhängen, liefert der Compiler immer eine Warnung, dass die Klasse (in der oben beschriebenen Reihenfolge) evtl. nicht auf methodeB reagiert.
Eine Lösung wäre eben, beide Methoden im Header zu deklarieren -- wo ja aber gesagt wurde, dass man das mit privaten Methoden nicht machen soll.

Original von zermelo

Original von gritsch
was haben PRIVATE methoden in einem prototyp zu suchen...?

Sorry, ich weiss nicht, wie man das in Objective-C nennt. Ein Prototyp ist in C/C++ eine Vorab-Deklaration einer Methode.
Ich weiss gar nicht, wie man soetwas in Objective-C macht, ganz so einfach scheint das nicht.
Nimm folgendes Beispiel und stell Dir vor, beide Methoden sollen privat sein:

Quellcode

1. - (int) methodeA:(int)val {
2. if(val==0) {
3. return 666;
4. }
5. return [self methodeB:val];
6. }
7. - (int) methodeB:(int)val {
8. return [self methodeA:0] + val;
9. }

Da beide voneinander abhängen, liefert der Compiler immer eine Warnung, dass die Klasse (in der oben beschriebenen Reihenfolge) evtl. nicht auf methodeB reagiert.
Eine Lösung wäre eben, beide Methoden im Header zu deklarieren -- wo ja aber gesagt wurde, dass man das mit privaten Methoden nicht machen soll.

In C++ sind Protoypen auch nur ein Spezialfall der Forward-Declaration. Und so heißt das dann auch in Objective-C.

Da es Kategorien gibt, ist es überhaupt kein Problem, wie Grtsch schon gezeigt hat. Es sei nur angemerkt, dass die Definition nicht in der Kategorie erfolgen muss. Es geht auch in der Klassenimplementierung.