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."?

  • 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."?

    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 habe nicht wirklich lust einen cryptischen prefix a la "GG45748748" zu verwenden...

    wie macht ihr das so?

    besten dank und schöne grüße

  • Auch wenn es vlt blöde klingt, aber die sicherste Methode ist es, es MyCar zu nennen wenn man seinen Code nicht weitergeben will.
    "My" als Prefix benutzt zwar jeder bei seinem Code aber in ein Framework packt das niemand rein.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Auch wenn es vlt blöde klingt, aber die sicherste Methode ist es, es MyCar zu nennen wenn man seinen Code nicht weitergeben will.
    "My" als Prefix benutzt zwar jeder bei seinem Code aber in ein Framework packt das niemand rein.

    Gruß

    Claus


    darauf möchte ich mich aber nicht verlassen. plötzlich lagert jemand bei seinem tool code in ein framework aus welches er vorher nach der My-Regel erstellt hat und schon hat man ein problem.

  • Du könntest Amin fragen. Also ob Namespaces nicht eine sinnvolle Erweiterung für Objective-C wären, weil sie ja Dein Problem hier lösen würden.
    Dann hättest Du Spass! Dann macht er wieder so Linien:

    _________________________
    Trage da ein, welche Frameworks in echt beide GGCar nehmen und in welchem Zusammenhang!
    ♥C++

  • Achso, und er würde Dir sagen, dass Du selten Blöd bist, deine Klasse "GGCar" zu nennen. Jeder Trottel weiss doch inzwischen, wie man ordentlich Symbole in Obj-C bezeichnet! Darum sind Namespaces überflüssig!

    Also: Bei Dir:
    GritschSeinAutoProjektCar

    Problem gelöst!
    Wofür also brauchst Du Namespaces?

    ______________________


    ...kannst ja mal den Thread hervorsuchen. war schön ;)
    ♥C++

  • zerm schrieb:

    Achso, und er würde Dir sagen, dass Du selten Blöd bist, deine Klasse "GGCar" zu nennen. Jeder Trottel weiss doch inzwischen, wie man ordentlich Symbole in Obj-C bezeichnet! Darum sind Namespaces überflüssig!

    Also: Bei Dir:
    GritschSeinAutoProjektCar

    Problem gelöst!
    Wofür also brauchst Du Namespaces?

    ______________________


    ...kannst ja mal den Thread hervorsuchen. war schön ;)



    dann geht aber trotzdem ein konkurrent meiner software her und erstellt aus jux und ollerei 3 frameworks mit einer klasse GritschSeinAutoProjektCar. schon stehen die chanchen 75/100 dass mein programm nicht startet...

  • gritsch schrieb:

    dann geht aber trotzdem ein konkurrent meiner software her und erstellt aus jux und ollerei 3 frameworks mit einer klasse GritschSeinAutoProjektCar. schon stehen die chanchen 75/100 dass mein programm nicht startet...

    Dann lasse Dir die Marke "GritschSeinAutoProjektCar" eintragen und verklage ihn...

    Ich denke ein Konkurrent ist schon selten dämlich und selber schuld wenn er sein Framework so nennt.

    Außerdem habe ich noch nicht verstanden wie ein fremdes Framework in Deine Applikation reinkommt. Wenn Du nicht dagegen linkst dann sucht der Loader gar nicht danach. D.h. neben dem Klassennamen muss auch noch der Frameworkname übereinstimmen.

    Oder hast Du nachladbare Bundles und befürchtest dass da jemand falsche Bundles installiert?

    Übrigens macht sich Apple keine solchen Sorgen: Wenn Du ein Bundle lädst und da ein NSWindow (nicht als Kategorie) definierst, dann bist Du selber schuld...

    -- hns

  • Da würden aber Namespaces auch nicht unbedingt helfen? Mhh
    Du musst ja das Framework Deines Konkurrenten schon verlinken, sonst ist doch die Doppelt-Bezeichnung kein Problem?!

    Such doch mal den Thread, ich will da nicht unbedingt dran erinnert werden. Jedenfalls hatte ich da ene Stack-Overflow Frage mit diesem Problem genannt, Wenn ich mich recht entsinne gab es da auch fiese Workarounds...
    ♥C++

  • gritsch schrieb:

    zerm schrieb:

    Achso, und er würde Dir sagen, dass Du selten Blöd bist, deine Klasse "GGCar" zu nennen. Jeder Trottel weiss doch inzwischen, wie man ordentlich Symbole in Obj-C bezeichnet! Darum sind Namespaces überflüssig!

    Also: Bei Dir:
    GritschSeinAutoProjektCar

    Problem gelöst!
    Wofür also brauchst Du Namespaces?

    ______________________


    ...kannst ja mal den Thread hervorsuchen. war schön ;)



    dann geht aber trotzdem ein konkurrent meiner software her und erstellt aus jux und ollerei 3 frameworks mit einer klasse GritschSeinAutoProjektCar. schon stehen die chanchen 75/100 dass mein programm nicht startet...

    Und ein Namespace würde was helfen?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • zerm schrieb:

    Du könntest Amin fragen. Also ob Namespaces nicht eine sinnvolle Erweiterung für Objective-C wären, weil sie ja Dein Problem hier lösen würden.
    Dann hättest Du Spass! Dann macht er wieder so Linien:

    _________________________
    Trage da ein, welche Frameworks in echt beide GGCar nehmen und in welchem Zusammenhang!

    Nein, sie würden sein Problemnicht lösen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Wir müssen nicht nochmal darüber diskutieren, Amin. Das endet ohnehin fruchtlos.

    Aber Du kannst mir gerne hier eintragen, wo in der Praxis Namenskollisionen in C++ schonmal aufgetreten sind:

    ______________________________________
    Ein Link auf ein Forums-Post oder SO reicht schon, wenn der Fragende nicht total dämlich. Selbst total dämliche Fragen finde ich auf Anhieb nicht.

    PS: Ich habe mich grad neulich wieder extrem geärgert, dass <Cocoa/Cocoa.h> einfach MIN in den globalen Namespace zieht. Aber das war ich ja mit min/max schon von Windows gewöhnt...
    ♥C++

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von zerm ()

  • Ich wollte das auch nicht diskutieren, sondern wissen, wieso ein Namespace das verhindert. Können Namespaces nicht kollidieren? Übirgens vestehe ich nicht, warum du das off-topic in die Diskussion einführst, wenn du es nicht diskutieren willst. Kannnst du mir das bitte auch erläutern?

    Danke!

    Ich hatte das weder in Objective-C noch in C++. Ich hätte ja auch gerne das konkrete Beispiel. Das ist aber noch nicht genannt worden. Wahrscheinlich fällt dann gritsch aber morgen ein, dass er es nicht posten kann, weil es mehrere 100 Zeilen Code sind - um etwas zu tun, was man in 5 Zeilen erledigen könnte.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Ich wollte das auch nicht diskutieren, sondern wissen, wieso ein Namespace das verhindert. Können Namespaces nicht kollidieren?

    Namespaces können natürlich auch kollidieren. Das ist nur so unwahrscheinlich, dass es so gut wie nie auftritt. Unter anderem, weil man nicht zu kurze Namen aus Faulheit wählt. Weil man Schachteln kann. Weil man idR nichts in den globalen Namespace zieht. Weil man auf TU-Level anonyme Namespaces definieren kann.

    Namenskollisionen in der Praxis von Obj-C: Dieser Thread, der alte Thread.
    Namenskollisionen in der Praxis von C++: _______________________

    Übrigens kann man, wie ich finde, Namespaces in C++ deutlich einfacher umbenennen, falls man doch mal Probleme bekommen sollte. In Obj-C muss man alle Klassen umbenennen.
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Ich wollte das auch nicht diskutieren, sondern wissen, wieso ein Namespace das verhindert. Können Namespaces nicht kollidieren?

    Namespaces können natürlich auch kollidieren. Das ist nur so unwahrscheinlich, dass es so gut wie nie auftritt. Unter anderem, weil man nicht zu kurze Namen aus Faulheit wählt. Weil man Schachteln kann. Weil man idR nichts in den globalen Namespace zieht. Weil man auf TU-Level anonyme Namespaces definieren kann.

    So, so, man kann nicht längere Prefixe als GG verwenden?
    So, so, man kann ein Prefix nicht lokal strukturieren?
    So, so, man kann Prefixe nicht schachteln?

    Ich kann das alles. Wurde sogar hier als Vorschlag gemacht. Aber irgendwie schien ja GritschSeinAutoProjekt.Car weniger lustig zu sein als GritschSeinAutoProjektCar. Mutmaßlich ist der Punkt ein Humortöter.

    zerm schrieb:

    Namenskollisionen in der Praxis von Obj-C: Dieser Thread, der alte Thread.
    Namenskollisionen in der Praxis von C++: _______________________

    Übrigens kann man, wie ich finde, Namespaces in C++ deutlich einfacher umbenennen, falls man doch mal Probleme bekommen sollte. In Obj-C muss man alle Klassen umbenennen.

    Weder in diesem noch im alten Thread habe ich ein konkretes Problem. Mal schauen, ob die Klasse noch genannt wird.

    Übrigens weiß ich nicht, was an Refactor so kompliziert ist.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Thallius schrieb:

    Nenn Deine Klassen doch einfach MyKlasse und mach am Ende ein global Search/Replace mit My/MeinName oder ähnliches

    Gruß

    Claus

    Es spielt ja letztlich keine Rolle, ob ich das My.Klasse oder MyKlasse oder EinSehrlangeName.Klasse oder EinSehrLangerNameKlasse nenne. Der einzige Vorteile von Namespaces ist, dass ich mit using mir Tipparbeit in der Verwendung erspare. Und das zu Zeiten der Code-COmpletion als Argument ... Da fällt mir übrigens ein, dass mal Bezeichner auf 8 Zeichen begrenzt waren. Da hat man noch geschwitzt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Thallius schrieb:

    Nenn Deine Klassen doch einfach MyKlasse und mach am Ende ein global Search/Replace mit My/MeinName oder ähnliches

    Gruß

    Claus

    Es spielt ja letztlich keine Rolle, ob ich das My.Klasse oder MyKlasse oder EinSehrlangeName.Klasse oder EinSehrLangerNameKlasse nenne. Der einzige Vorteile von Namespaces ist, dass ich mit using mir Tipparbeit in der Verwendung erspare. Und das zu Zeiten der Code-COmpletion als Argument ... Da fällt mir übrigens ein, dass mal Bezeichner auf 8 Zeichen begrenzt waren. Da hat man noch geschwitzt.


    Sehe ich genauso. Aber Tippfaul ist halt jeder und das AutoCompletion ist nicht wirklich schnell auf meinem MBP. Also wenn ich tippe, dann bin ich schneller mit dem Wort fertig als das er eins vorschlägt. Darum nehme auch ich lieber was kurzes, habe aber tatsächlich schon öfter einen Refraktor gemacht um einer fertigen Klasse einen aussagekräftigereren Namen zu geben.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)