Kritik am Forum..

Original von AyaKoshigaya
Aber egal, die diskussion führt zu nichts.
Ich werde hier in diesem Forum wohl nie die Antworten bekommen die ich erwarten würde - jetzt erst recht nichtmehr.. und ihr seht nichtmal im Ansatz worum es mir ging, bzw. seid nicht der Meinung das dies etwas verbesserungswürdiges wäre. Insofern... den Thread hier werd ich wohl noch verfolgen falls ne Mail Benachtichtigung kommt, bin aber ansonsten dann mal weg.

Aya

Hör auf zu jammern und beherzige die Ratschläge. Lesen, lesen, lesen und natürlich auch probieren.

Du bist mit dem Mac in einer anderen Welt gelandet, longW hat das schön ausgedrückt. Vergiss alles was du über Delphi und Windows weist. Hier gibt es nicht nur eine neue Programmiersprache sondern eine ganz neue Philosophie. Der musst du folgen oder du machst dir das Leben unnötig schwer.

Und um mal bei deinem selbstgewählten Beispiel zu bleiben

Original von AyaKoshigaya
Na ja, du hast mir ja geschrieben das es dieses delegate bei NSApplication gibt.
Das habe ich bei mir nachgeschaut und... bei mir gibt es eben kein NSApplication Object, sondern nur die NSApplicationMain() funktion.

Hab dann im nachhinein rausgefunden das die einfach nur intern das gleiche macht, als wenn ich von hand dashier aufrufe:

Quellcode

1. NSApplication *app = [NSApplication sharedApplication];
2. [NSBundle loadNibNamed:@"MainMenu" owner:app];
3. [app run];

Das wäre die antwort gewesen die ich mir erhofft hätte.. also vonwegen "nimm die 3 zeilen code statt der einen und leite ne eigene klasse von NSApplcation ab für's delegate" - grob gesagt.

Du schreibst dass es bei dir kein NSApplication Objekt gibt, holst es dir aber in der ersten Codezeile. ???
Doku zu NSApplication angesehen? ich vermute ja, sonst hättest du den Code nicht gepostet. Im Overview zu NSApplication steht auch was über Delegates und Subclassing. In den Instance Methods steht sogar dass es die Methoden delegate und setDelegate gibt. Wenn du dir das auch durchgelesen hättest würdest du dich nicht über die fehlende falsche Antwort: "also vonwegen "nimm die 3 zeilen code statt der einen und leite ne eigene klasse von NSApplcation ab für's delegate" - grob gesagt." beschweren sondern hättest gefragt wie man den Delegate setzt.

Nicht nur anderen mangelnde Hilfsbereitschaft vorwerfen sondern selbst versuchen die OS X Philosophie zu verstehen. Und wenn jemand von mangelnder Kenntnis spricht hat das absolut nicht mit deinem Können zu tun sondern bezieht sich auf deine Cocoa Kenntnisse, da haben wir alle bei 0 angefangen. Und dass es dir noch an Verständnis mangelt ersieht man aus deiner Antwort an longW aus der ich zitiert habe. Es liegt an dir die fehlenden Kenntnisse zu erarbeiten, nicht am Forum.
Gute Bücher helfen da. Entweder Amins Buch oder das von Aaron Hillegass. Andere kann ich nicht beurteilen.

Chris

Zum Thema „elitärer Kreis“.

„We're all old grumpy men“ – würde Aaron Hillegass sagen. Und dann dieses Buch nach Dir werfen

Original von AyaKoshigaya

Original von Lucas de VilWeiterhin bietet Cocoa für fast jeden Mist irgendwas. Die einzelnen Frameworks sind nicht deshalb so riesig, weil den Entwicklern langweilig war. Etwas zu finden, für das Cocoa keine tolle Lösung bietet ist schwierig. Und wenn man doch etwas gefunden hat, dann ist es so speziell, dass man schon ein gewisses Grundverständnis haben muss, um überhaupt so etwas realisieren zu wollen.
In dem Fall wird dann einfach mit reinen und beschissen dokumentierten C-Funktionen herumhantiert.
zermelo kann da sicherlich ein Liedchen von trällern.

Tja das ist das was ich meinte... dinge die Cocoa eben nicht für einen bereit stellt stellen wohl für viele Mac Programmierer eine Hürde dar.. das meinte ich mit "zusammen klicken und über Cocoa freuen".

Schön, dass du das so meinst. Steht da aber nicht.
Ich für meinen Teil schreibe was ich meine, auch wenn ich mir dann eine Rüge einfange.
Selbst wenn meine Einschätzung wie von longW nicht geteilt wird.
(zermelo: Dich hab ich in der dritten Kategorie doch schon fast namentlich genannt. ;))
Es ist auf jeden Fall ehrlicher als Dinge eindeutig und unmissverständlich zu formulieren und im Nachhinein zu behaupten, es würde etwas hineininterpretiert werden.

Nun unterstelle ich dir, dass du meine Grundaussage nicht verstanden hast, deshalb wiederhole ich sie gern noch einmal:

Sämtliche deiner 'Probleme' konntest du mit Cocoa lösen, so what?

Original von AyaKoshigaya

Original von Lucas de Vil
Insofern lässt deine Behauptung einen totalen Kenntnismangel vermuten.

Und nochjemand der mir kenntnismangel vorwirft... juchu...

Steht da nicht.
Da steht: "Deine Behauptung lässt totalen Kenntnismangel vermuten."
Da steht nicht: "Bei dir mangelt es an Kenntnis."
Ich schreibe immer, was ich meine. Eindeutig und unmissverständlich.

Original von AyaKoshigaya
Du hast in meinen Satz etwas völlig anderes hinein interpretiert... du sagst selbst das viele Leute keinen Plan davon haben sich mit dingen rumzuschlagen die in Cocoa nicht vorgesehen sind, unterstellst mir aber kenntnismangel weil ich das gleiche sage..

Nö. Ich sage, dass viele Leute keinen Plan davon haben sich mit Dingen rumzuschlagen, die in Cocoa nicht vorgesehen sind. Ich sage, dass liegt daran, dass es nur sehr weniges und spezielles gibt, dass ich Cocoa nicht vorgesehen ist. Das meine ich auch so.

Du sagst, dass viele Leute keinen Plan davon haben sich mit Dingen rumzuschlagen, die sie sich nicht mal eben schnell über Cocoa zusammenklicken können. Wenn du damit etwas Anderes gemeint hast, dann kann ich das nicht riechen.

Da du laut deiner Aussage 'Cocoa' und 'Zusammenklicken' im IB gleich setzt, kann man zu dem Schluss kommen, dass es dir da an Kenntnis mangelt. Ich persönlich denke nicht, dass es dir an Kenntnis mangelt, sondern an etwas Anderem. Das gehört hier aber nicht her.
Solltest du irgendwann mal auf meine Mail antworten kannst du darin ja um eine Einschätzung bitten.

Original von AyaKoshigaya

Original von Lucas de VilObjective-C und Cocoa haben mal gar nix mit Delphi gemein. Eher mit C# und .NET.

Ich sprach nicht von der "Art" der Sprache, sondern von den Anwendern. Und die ähneln sich doch in den Grundzügen recht stark. Wobei der vergleich mit C#/.NET Anwendern natürlich auch sehr ähnlich ist.

Und wieder: was meinst du?
Die Anwender von Objective-C&Cocoa sind denen von Delphi ähnlich? Ja, ziemlich. Sie erstellen Programme. Da unterscheiden sie sich kein Stück von den Anwendern von PHP, C++, COBOL, FORTRAN, PASCAL oder BASIC.
Sie erstellen auch noch hauptsächlich graphische Anwendungen, wobei COBOL, FORTRAN, PASCAL und BASIC dann rausfallen könnten.

Und sonst? Wenn dir Delphi eine Möglichkeit nicht bietet, dann biste in den Allerwertesten gekniffen und du musst auf die Grundmethoden und -funktionen von Delphi zurückgreifen. Wenn es dafür keine gibt wird es noch schlimmer, du musst irgendwelche seltsamen Bridges nutzen und beispielsweise in C/C++ weitermachen. Das sind zwei völlig unterschiedliche Sprachen und Konzepte, die du irgendwie verschmelzen musst.

Wenn du in Cocoa/.NET nicht weiterkommst, dann greifst du auf die Sprache außerhalb des Frameworks zu: Objective-C/C#.
Wenn du da auch nicht weiter kommst (und das ist halt ausgesprochen selten und tritt meines Wissens hauptsächlich im Bereich der konkreten Hardwareansteuerung auf), dann nutzt du C.
Sowohl Objective-C als auch C# basieren auf C. Du musst nicht großartig umdenken, denn im Prinzip nutzt du es ja die ganze Zeit.

Original von AyaKoshigaya
Aber egal, die diskussion führt zu nichts.

Das sehe ich mittlerweile auch so.
Dass sie nicht zu dem von dir erwünschten Ergebnis führt, war mir von Anfang an klar. Schließlich meinst du irgendwas in deinem Eröffnungspost ohne es zu schreiben, keiner hier kann offenbar nachvollziehen was du meinst und du gibst auch keine Beispiele dafür. Allgemeine Floskeln, aber keine Beispiele.
Tatsächlich sehe ich sogar, dass der einzige mir bekannte aktive Verfechter von C++, der sich oftmals ein Späßchen daraus macht die Objective-C Fraktion aufzuziehen, keine Ahnung hat was du eigentlich erwartest.

Original von AyaKoshigaya
Ich werde hier in diesem Forum wohl nie die Antworten bekommen die ich erwarten würde - jetzt erst recht nichtmehr.. und ihr seht nichtmal im Ansatz worum es mir ging, bzw. seid nicht der Meinung das dies etwas verbesserungswürdiges wäre. Insofern... den Thread hier werd ich wohl noch verfolgen falls ne Mail Benachtichtigung kommt, bin aber ansonsten dann mal weg.

Nein, sehe ich nicht. Schreibst du ja auch nicht. Oder du meinst was Anderes, als das was du schreibt. Aber das ist dann weder meine Schuld noch mein Problem.
Wenn dir ausführliche und ehrliche Antworten nicht reichen und du schlichtweg der Meinunng bist man müsse dir gefälligst erklären, wie du mit festgefahrenen C++-Ansätzen in Objective-C arbeiten kannst, dann wirst du auf deine Fragen tatsächlich nichts Hilfreicheres bekommen als 'geht so nicht, lies was Einführendes'.

Hallo,

ich klinke mich hier mal in die kleine Dikussion ein.

1. Dieses Forum ist nach meiner Ansicht ein recht gutes Entwicklerforum. Als "elitären Kreis" würde ich die Leute hier aber nicht beszeichnen. Hier wird Dir gerne mal auf die Sprünge geholfen oder auf eine (gute) Buch/Doku verwiesen. Und solche Verweise finde ich nicht weiter schlimm, ich kaufe mir gerne gute Fachbücher weil diese einfach praktischer sind und i.d.r. ausführliche.

1.5. ich habe hier auch ein mal eine "dumme" Frage gestellt und darauf "KEINE" dumme Antwort bekommen, sondern einen guten Hinweis als "Anstupser". Ich habe ja mein Kopf zum denken und nicht um eine Frisur herum zu tragen.

1.75 lesen, lesen, lesen... üben, üben, üben...

2. Man sollte denn Fehler vermeiden OBJ-C mit C zu vermischen. Der Compiler lässt dieses zwar zu (muss er ja auch OBJ-C ist ja eine Mischung aus Smaltalk und C/C++ und ich habe das ungute gefühl das im Hintergrund reines C arbeitet - daher OBJ-C mir manchmal mehr wie eine script-sprache vorkommt.) aber erzeugt dann unschöne Seiteneffekte und macht den Code schwerer zu lesen. Aber diverse Designschwächen konnte ich auch im Framework und in OBJ-C ausmachen. Zweitens hat aber mit der Herkunft von OBJ-C zu tun.

Und mich freut das die Speicherverwaltung beim MAC genauso wenig funktioniert wie bei Win-Systemen.

Echte elitäre Kreise findest du in C/C++ Foren !!!!

Original von Kismet
2. Man sollte denn Fehler vermeiden OBJ-C mit C zu vermischen.

Wat is los?
Dein Gefühl trügt nicht, im Hintergrund arbeitet ne ganze Menge C. Quasi nur.
Man sollte schon zusehen, dass man mit Objekten statt mit Strukturen arbeitet, ja. Ansonsten isses aber C im Hintergrund.
Was auch immer dein Hinweis bzgl. C++ da jetzt verloren hat, den C++ hat mit Objective-C überhaupt nix mehr zu tun. Und umgekehrt.

Original von Kismet
2. Man sollte denn Fehler vermeiden OBJ-C mit C zu vermischen. Der Compiler lässt dieses zwar zu (muss er ja auch OBJ-C ist ja eine Mischung aus Smaltalk und C/C++ und ich habe das ungute gefühl das im Hintergrund reines C arbeitet - daher OBJ-C mir manchmal mehr wie eine script-sprache vorkommt.) aber erzeugt dann unschöne Seiteneffekte und macht den Code schwerer zu lesen. Aber diverse Designschwächen konnte ich auch im Framework und in OBJ-C ausmachen. Zweitens hat aber mit der Herkunft von OBJ-C zu tun.

Original von Lucas de Vil
Was auch immer dein Hinweis bzgl. C++ da jetzt verloren hat, den C++ hat mit Objective-C überhaupt nix mehr zu tun. Und umgekehrt.

Wenn ihr wuesstet, wie krass ich grade C++ mit Objective-C mische, wuerdet ihr euch wundern. Der kricht sogar namespaces und operator-overloading gebacken, der helle Wahnsinn

Freak.

Original von zermelo

Original von Kismet
2. Man sollte denn Fehler vermeiden OBJ-C mit C zu vermischen. Der Compiler lässt dieses zwar zu (muss er ja auch OBJ-C ist ja eine Mischung aus Smaltalk und C/C++ und ich habe das ungute gefühl das im Hintergrund reines C arbeitet - daher OBJ-C mir manchmal mehr wie eine script-sprache vorkommt.) aber erzeugt dann unschöne Seiteneffekte und macht den Code schwerer zu lesen. Aber diverse Designschwächen konnte ich auch im Framework und in OBJ-C ausmachen. Zweitens hat aber mit der Herkunft von OBJ-C zu tun.

Original von Lucas de Vil
Was auch immer dein Hinweis bzgl. C++ da jetzt verloren hat, den C++ hat mit Objective-C überhaupt nix mehr zu tun. Und umgekehrt.

Wenn ihr wuesstet, wie krass ich grade C++ mit Objective-C mische, wuerdet ihr euch wundern. Der kricht sogar namespaces und operator-overloading gebacken, der helle Wahnsinn

Nicht der helle sondern der totale Wahnsinn. Muss mich auch gerade durch sowas quälen. Aber man ist ja hart im nehmen

Chris

Aber jetzt noch einmal richtige Kritik am Forum:

Original vom Forum, grade jetzt

Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /home/www/forum/acp/lib/functions.php on line 157

ist ja anstrengend. Ausserdem hat man PHP-Fehlerausgabe doch deaktiviert auf einem Produktivsystem!