Wie verhindert man am besten "Class GGCar is implemented in both $A and $B. One of the two will be used. Which one is undefined."?

Amin Negm-Awad · 1. Juni 2011, 09:17

gritsch schrieb:

Amin Negm-Awad schrieb:

Captain Obvious, willst du wirklich wissen, wie man damit umgeht, dass ein von einem selbst verwendete Framework denselben Klassennamen verwendet wie eine selbst geschriebene Klasse? Ganz einfach: Vor dem Programmieren einfach programmieren lernen. Solltest du mal befolgen.

Aber wie war das bei dir:
"Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

Ich bekomme und bekomme einfach das Problem nicht hin. Bitte erhelle mich.

ich verwende das private framework nicht. das wurde mir untergeschoben (von apple).

Eben. Deshalb war ja auch deine Anmerkung "dann füg doch das WebKit-Framework dazu!" offensichtlich nicht zielführend.

gritsch schrieb:

also was hat das mit wickeltisch zu tun? zeit in den sarg zu steigen oder was?

Deine Anmerkung lässt sich nur damit erklären, dass du vom Wickeltisch gefallen bist und seitdem einen Nachteil mit dir durch dein Leben trägst.

Aber du wolltest mir noch etwas dazu sagen:
"Also wenn ich in meinem code eine Klasse namens GGCar erstelle und dann durch irgend ein programm auf irgeneinem rechner irgendein framework installiert wird welches auch eine klasse GGCar enthällt kommt diese meldung."

Wenn dir Apple schon Dinge unterschiebt, wie machen das dann irgendwelche Frameworks, die mit irgendwlechen Programmen kommen? Möglicherweise leidest du auch an einer paranoiden Demenz.

Thallius · 1. Juni 2011, 09:19

Könnt ihr das Ganze nicht mal wieder auf eine sachliche Ebene bringen ?

Ich bin mir auch nicht sicher was gritsch eigentlich meint, aber eventuell ist es ja wirklich interessant. Ansonsten macht eure Anfeimdungen doch per PM weiter bitte.

Gruß

Claus

Amin Negm-Awad · 1. Juni 2011, 09:20

Er meint, dass die Installtion irgendwelcher Programme mit irgendwelchen Frameworks mit irgendwelchen Klassen in seinem Programm eine Kollision auslösen können.

Das ist falsch.

Kollisionen können nur mit dem von ihm verwendeten Frameworks und dem Laufzeitsystem entstehen. Bei Frameworks ist ein Prefix zu verwenden, so dass eine Klasse ohne ein solches ganz einfach buggy wäre: Bug-Report. Aber ins eigene Bundle kommen ja nicht einmal so eben mir nichts, dir nichts Frameworks.

Bei Klassen des Laufzeitsystems ist das theoretisch denkbar. Dazu hatte ich schon geschrieben.

mattik · 1. Juni 2011, 09:28

Amin Negm-Awad schrieb:

Ich bekomme und bekomme einfach das Problem nicht hin. Bitte erhelle mich.

Wie das mit Frameworks von Drittherstellern funktionieren soll ist mir auch schleierhaft. Aber es kann schon vorkommen, dass implizit ObjC-Klassen von Dritten geladen werden. Ich hatte ein ähnliches Problem mal mit einem QuickTime-Plugin (war aber kein Namespace-Konflikt). Sobald ein Programm ein Bild laden wollte, wurde automatisch QuickTime geladen, um an die Codecs zu kommen. Und QuickTime hat alle installierten Plugins geladen (auch Nicht-Codecs). Falls dort ObjC-Code drin war, wurden die Klassen initialisiert. Und so konnte es passieren, dass ein Programm plötzlich multithreaded wurde, obwohl man selbst gar keinen Thread gestartet hatte. Ist schon etwas her, kann sein, dass das mittlerweile nicht mehr so ist.

gritsch · 1. Juni 2011, 09:32

ich hatte auch mal das problem dess irgend ein tool eine Category für NSArray geschrieben hatte:

Quellcode

- (id)firstObject { return [self objectAtIndex:0]; }

bei mir ist dann das ganze programm gecrasht weil ich auch eine NSArray-Cateory mit firstObject hatte, in dieser aber sinnvollerweise die länge des arrays geprüft habe.

wie das reinkam und um welches tool es sich handelte weis ich nicht mehr (müsste ich im bugtracker suchen)

Amin Negm-Awad · 1. Juni 2011, 09:32

mattik schrieb:

Amin Negm-Awad schrieb:

Ich bekomme und bekomme einfach das Problem nicht hin. Bitte erhelle mich.

Wie das mit Frameworks von Drittherstellern funktionieren soll ist mir auch schleierhaft. Aber es kann schon vorkommen, dass implizit ObjC-Klassen von Dritten geladen werden. Ich hatte ein ähnliches Problem mal mit einem QuickTime-Plugin (war aber kein Namespace-Konflikt). Sobald ein Programm ein Bild laden wollte, wurde automatisch QuickTime geladen, um an die Codecs zu kommen. Und QuickTime hat alle installierten Plugins geladen (auch Nicht-Codecs). Falls dort ObjC-Code drin war, wurden die Klassen initialisiert. Und so konnte es passieren, dass ein Programm plötzlich multithreaded wurde, obwohl man selbst gar keinen Thread gestartet hatte. Ist schon etwas her, kann sein, dass das mittlerweile nicht mehr so ist.

Das kann ich mir gut vorstellen. Aber du lädst dann ja ein Framework, welches Code nachlädt – und weißt daher von diesem Problem. Ist nicht schön, weil du Codecs natürlich nicht alle kennen kannst. Ist aber auch die Ausnahme. (Multithreaded finde ich übrigens gar nicht überraschend. Das weißt du doch ohnehin nie, ergo musst du damit rechnen.) Da ist das Laufzeitproblem schon schwieriger. Ich hatte auf der Macoun zu AOP das erste Mal eine neue Betriebssystemversion (.6?). Da wunderte ich mich auch, dass die Klassenliste länger geworden war. Und theoretisch kann da ein Programm auch abrauchen. Aber wie häufig wird das Laufzeitsystem geändert? Muss man eben ein Update machen. (Die Klassennamen waren da aber auch nichts sagend, da natürlich im RTE mit sehr allgemeinen Begriffen gearbeitet wird, die niemand bei Verstand in siner Applikation verwenden würde. Aber es gab auch Dinger wie NSMessageBuilder, IIRC.)

Dass irgendwer ein Programm installiert und deshalb ein Namenskonflikt entsteht, halte ich aber auch für völlig ausgeschlossen. Daher muss man mit dem Problem gar nicht umgehen.

mattik · 1. Juni 2011, 09:44

Amin Negm-Awad schrieb:

Das kann ich mir gut vorstellen. Aber du lädst dann ja ein Framework, welches Code nachlädt – und weißt daher von diesem Problem.

Das Ekelige daran war, dass der Code auch von Programmen geladen wurde, die gar nicht explizit gegen QuickTime gelinkt hatten. NSImage (oder ImageIO oder weißnichtwer) waren so frei, das einfach mal so zu tun. Kann aber sein, dass das mittlerweile nicht mehr passiert. Müsste man bei Gelegenheit mal ausprobieren.

Mutlithreaded war für mich auch nicht das Problem. Ich hatte damals das plugin geschrieben und bekam Beschimpfungen von irgendwelchen Carbon-Entwicklern, wie ich die Frechheit hätte, in meinem Plugin die ObjC-Runtime zu starten. Leute gibt's...

Amin Negm-Awad · 1. Juni 2011, 09:49

mattik schrieb:

Amin Negm-Awad schrieb:

Das kann ich mir gut vorstellen. Aber du lädst dann ja ein Framework, welches Code nachlädt – und weißt daher von diesem Problem.

Das Ekelige daran war, dass der Code auch von Programmen geladen wurde, die gar nicht explizit gegen QuickTime gelinkt hatten. NSImage (oder ImageIO oder weißnichtwer) waren so frei, das einfach mal so zu tun. Kann aber sein, dass das mittlerweile nicht mehr passiert. Müsste man bei Gelegenheit mal ausprobieren.

Mutlithreaded war für mich auch nicht das Problem. Ich hatte damals das plugin geschrieben und bekam Beschimpfungen von irgendwelchen Carbon-Entwicklern, wie ich die Frechheit hätte, in meinem Plugin die ObjC-Runtime zu starten. Leute gibt's...

Absatz 1:
Das ist natürlich überraschend und daher eklig. Na, ja, QT war ja lange Zeit ein "Parallelbetriebssystem". Gibt es eigentlich keine Naming-Rules für QT-Plugins?

Absatz 2:
Ist natürlich geil.

BTW: NSMessageBuilder war nicht einmal eine RT-Klasse, sondern eine weitere Basisklasse von Foundation, IIRC.

Amin Negm-Awad · 1. Juni 2011, 10:31

gritsch schrieb:

ich hatte auch mal das problem dess irgend ein tool eine Category für NSArray geschrieben hatte:

Quellcode

- (id)firstObject { return [self objectAtIndex:0]; }

bei mir ist dann das ganze programm gecrasht weil ich auch eine NSArray-Cateory mit firstObject hatte, in dieser aber sinnvollerweise die länge des arrays geprüft habe.

wie das reinkam und um welches tool es sich handelte weis ich nicht mehr (müsste ich im bugtracker suchen)

mattik schrieb:

Amin Negm-Awad schrieb:

Es geht sogar ein simpler #define.

Du erwähnst dieses Teufelszeug als Möglichkeit? Dass ich das noch erleben darf...

Ich habe kein Problem mit Defines. Ich habe ein Problem damit, dass diese für allerlei Lösungen dumm empfohlen werden.

Und nein, für dieses Problem habe ihc es nicht empfohlen. Ich habe das Problem gar nicht. Ich wollte lediglich andere auf diese Möglichkeit hinweisen.