Ja, es wäre besser lesbar. ^^ Ob es vernachläsigbar ist, oder nicht, soll jeder selbst entscheiden, aber einen Buchstaben weniger lesen zu müssen, auf den man sowieso verzichten kann, ist definitiv ein Gewinn.
Das ist genauso wie Klassennamen in C++ ein "C" voranzustellen um anzumerken, dass es sich um eine Klasse handelt (ja, Leute, die das machen, die aber nicht wissen, dass der Grund für den "C"-Präfix, den Microsoft "erfunden" hat, ein anderer war, als anzudeuten, dass es sich um eine Klasse handelt, gibt es genug).
Ruby hat auch keinen new-Operator und kann ohne Präfixe auskommen. ^^
Du kämpfst auf verlorenem Posten, weil du einen Designfehler zu verteidigen versuchst.
Methodennamen (sowie Prozeduren/-Funktionsnamen) müssen immer das wiedergeben, was sie tun (eine der wichtigsten Regel in der Programmierung) und bei einer Methode, die Create heißt und auf ein Objekt des Typs Object angewendet wird, erwarte ich die Erzeugung einer neuen Instanz des Typs Object. Das wird bei einem Objekt vom Typ ObjectManager auch nicht mehrdeutig. Sollte eine Methode etwas anderes machen, als eine neue Instanz des Typs zurückzugeben, auf dem sie angewendet wird, darf sie nicht Create oder New oder ähnlich heißen. Im Falle, dass ObjectManager eine neue Instanz vom Typ Object zurückgeben soll, muss die Methode auch entsprechend aussehen, also z.B. CreateObject oder CreateNewObject oder ähnlich.
Dito mit kyuu. Objective-C hat auch keinen new-Operator und Klassen haben oft mehrere Konstruktoren mit verschiedenen Namen. Konventionen helfen hier.
Grundlegenderweise allokiert man ein Objekt so: NSString* foo = [NSString alloc]; (Der NS-Präfix identifiziert die Klasse als Teil der Standardbibliothek und ist kurz für "NeXTStep".)
Die so erzeugte Instanz muß man dann noch initialisieren. Im einfachsten Fall sieht das so aus: [foo init];
Wenn man mit Parametern initialisieren will, dann muß man eine entsprechende Funktion dafür bereitstellen: [foo initWithString:someString];
Jetzt ist es umständlich, immer NSString* foo = [[NSString alloc] initWithString:someString]; zu schreiben, also gibt es für so etwas statische Wrapper. Mit denen sieht das dann so aus: NSString* foo = [NSString stringWithString:someString];
Jeder Obj-C-Entwickler erkennt sofort, daß initWithFoo:bar: das Objekt mit einem foo und einem bar initialisiert oder daß [Foo foo] eine statische Methode ist, die ein Foo allokiert und initialisiert. Schlicht, weil die Stilrichtlinien der Sprache und alle sinnvollen Codebeispiele (vor Allem natürlich die ganze API) einem genau das vorleben.
Letztenendes ist das auch nur eine Konvention, aber es ist eine, die den Code schön lesbar hält.
Ruby hat auch keinen new-Operator und kann ohne Präfixe auskommen. ^^
Du kämpfst auf verlorenem Posten, weil du einen Designfehler zu verteidigen versuchst.
...
Verloren ja, aber Designfehler? Ansichtssache. z.B. erkenne ich bei Objectiv-C nicht im geringsten was passiert, da es für meine Verhältnise oder Vorstellungen einfach viel zu kryptisch ist.
Zitat von Jesus_666
Jeder Obj-C-Entwickler erkennt sofort, daß initWithFoo:bar: das Objekt mit einem foo und einem bar initialisiert oder daß [Foo foo] eine statische Methode ist, die ein Foo allokiert und initialisiert.
...
Aber eben nur die erkennen es. Wenn man mal ganz ehrlich ist, so kann man nicht darauf schließen wenn man [[NSString alloc] initWithString:someString]; sieht, dass dort etwas erzeugt wird. Designfehler? Eben Ansichtssache.
Zitat von Kyuu
Ja, es wäre besser lesbar. ^^ Ob es vernachläsigbar ist, oder nicht, soll jeder selbst entscheiden, aber einen Buchstaben weniger lesen zu müssen, auf den man sowieso verzichten kann, ist definitiv ein Gewinn.
(ja, Leute, die das machen, die aber nicht wissen, dass der Grund für den "C"-Präfix, den Microsoft "erfunden" hat, ein anderer war, als anzudeuten, dass es sich um eine Klasse handelt, gibt es genug).
...
Mal blöd und rein interessehalber in die Runde gefragt: Was war der Grund?
Mal blöd und rein interessehalber in die Runde gefragt: Was war der Grund?
...
Zur damaligen Zeit waren Namespaces noch nicht Teil des C++-Standards und Programmierer, aber besonders Unternehmen wie Microsoft hatten bei ihren Bibliotheken mit Namenskollisionen zu kämpfen. Z.B. gab es Kollisionen bei allgemeinen Namen wie String oder Vector. Um dieses Problem zu bewältigen, entschied sich Microsoft bei seinen MFC-Klassen ein "C" voranzustellen (aus welchen Gründen auch immer; eventuell ist sogar etwas von dem Hype um die Ungarische Notation reingeflossen). Das ging auch einige Zeit gut, bis andere Programmierer es besonders toll fanden und ebenfalls bei ihren Klassen ein "C"-Präfix verwendeten und schon hatte man das Problem wieder. In neueren Projekten (z.B. das NET-Framework) verzichtet Microsoft auf dieses Präfix bei Klassen und rät davon auch offiziell in den Guidelines ab.
@Desmulator:
Programmiersprachen sind natürlich nicht perfekt und jede Sprache hat ihre Macken und Fehler, aber ich würde schon zwischen subjektiven Wahrnehmungen, die z.B. aus fehlender Kenntnis über die Syntax resultieren, und Argumenten, die objektiv auf dem Vergleich aufbauen unterscheiden.
In C++ ist es z.B. ein Designfehler, dass die Templatesyntax "<" und ">" verwendet, weil das zu unnötigen Parsingkomplikationen führt und teilweise auch unlesbar werden kann, die andere, neuere Sprachen wie z.B. D nicht haben, weil sie aus der negativen Erfahrung gelernt haben. Diese Aussage ist objektiv. Natürlich kann man sich daran gewöhnen, aber das ist nicht der Punkt bei der Kritik.
Zitieren
