Punkt Notation

  • hns schrieb:

    MKMapView hat z.B. setVisibleMapRect: als @property und setVisibleMapRect:animated: Ersteren kann man als mapView.visibleMapRect= schreiben, den zweiten nicht.

    Erstere wird sicherlich sowieso nur -setVisibleMapRect:<rectParam> edgePadding:0.0 anitmated:YES aufrufen. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Also ich finde:

    Quellcode

    1. self.selectedNetwork = [self.scanResults objectAtIndex:index];
    2. joinNetworkNameField.stringValue = self.selectedNetwork.ssid;

    mittlerweile deutlich lesbarer als:

    Quellcode

    1. [self setSelectedNetwork:[[self scanResults] objectAtIndex:index]];
    2. [joinNetworkNameField setStringValue:[[self selectedNetwork] ssid]];

    Aber dies liegt ja, wie bereits erwähnt, im Auge des Betrachters. ;)
  • Lucas de Vil schrieb:

    Eine Notwendigkeit einen Getter auf self zu nutzen sehe ich bei vielen Klassen schlicht nicht.
    Nur den 'Erfolg' eine zusätzliche Nachricht in den Äther gejagt zu haben.


    Womit wir wieder beim leidigen Thema Multi-Threadding wären. Da macht es schon viel Sinn den Getter zu benutzen (Stichwort atomic), vor allem aber wenn man mit so Ekelsachen wie Locks arbeitet.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Zum Thema "Getter für eigene Instanzvariablen nutzen": Wenn in einer Klasse auch für den Zugriff auf Instanzvariablen Getter benutzt werden, hat das den unschlagbaren Vorteil, dass die Instanzvariable im Zuge der Evolution der Klasse jederzeit entfallen kann, sofern der Getter noch das erwartete liefert – ohne Modifikationen ausserhalb des Getters! Würde direkt auf die Instanzvariable zugegriffen werden, müsste in diesem Fall jeder einzelne Aufruf angepasst werden: Mühselig!

    McPringle
    Flattr this
  • McPringle schrieb:

    Zum Thema "Getter für eigene Instanzvariablen nutzen": Wenn in einer Klasse auch für den Zugriff auf Instanzvariablen Getter benutzt werden, hat das den unschlagbaren Vorteil, dass die Instanzvariable im Zuge der Evolution der Klasse jederzeit entfallen kann, sofern der Getter noch das erwartete liefert – ohne Modifikationen ausserhalb des Getters! Würde direkt auf die Instanzvariable zugegriffen werden, müsste in diesem Fall jeder einzelne Aufruf angepasst werden: Mühselig!

    McPringle


    nachteile gibts aber auch in bestimmten fällen (zb dass man unnötig viele kopien erstellt - und das können SEHR viele sein zb bei den datasource-funktionen von tabellen und co)
  • MCDan schrieb:

    D.h.

    Quellcode

    1. self.selectedNetwork = self.scanResults[index];

    würde jetzt auch funktionieren?

    Hm, da weiss ich noch nicht, ob mir dies wirklich gefällt.

    gerade das finde ich genial. Hat mich immer genervt, dass ich für sowas einfaches wie einen Eintrag aus einem Array zu bekommen eine ellenlange Methode objectAtIndex: aufrufen muss.

    Gruß

    Claus


    MCDan schrieb:

    Ok, passt nicht wirklich zum Thema Punkt Notation, aber seit wann kann man denn dies hier machen?

    Quellcode

    1. self.splitViewController.viewControllers = @[masterNavigationController, detailNavigationController];

    Also @[...] um ein NSArray zu erzeugen, oder verstehe ich hier etwas völlig falsch?
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • MCDan schrieb:

    D.h.

    Quellcode

    1. self.selectedNetwork = self.scanResults[index];

    würde jetzt auch funktionieren?

    Hm, da weiss ich noch nicht, ob mir dies wirklich gefällt.

    Dann könnten wir ja gleich Obj-C++ nehmen... Und was spart es groß gegenüber:

    Quellcode

    1. [NSArray arrayWIthObjects:@"1", other, nil];
    . Spart Tipparbeit - aber ist wieder eine Abkürzung die der Lesende (!) kennen muß.

    Mir gefällt das alles nicht. Ich bin da einfach "Purist" und finde das Obj-C1.0 wunderbar systematisch aufgebaut war. Eben von Mathematikern entwickelt und nicht von der Marketingabteilung. Hinter den Erweiterungen kann ich selten feststellen, dass sie sich ins System einfinden. Viele Köche verderben halt den Brei...

    Warum steht z.B. [] hier für ein Array? Das ist doch eine Anlehnung an C und Java. Und wie wird ein NSDictionary initialisiert? Eventuell @{} ? Wäre naheliegend. Aber warum dann @{} für Arrays und nicht @()? Das würde dann wenigstens zu den ASCII-Property-Lists passen. Das wäre z.B. eine tolle Sache, wenn man ganze PLists in den Source kopieren könnte.

    Ach geht ja schon: [@"(hier, dort)" propertyList];

    Also in Summe bin ich der Meinung: eine Programmiersprache ist umso leichter zu lesen und zu verstehen, um so weniger Regeln sie hat. Dadurch wird der Text manchmal etwas weitschweifiger und länger was nicht schlimm ist.
    Wer das nicht glaubt, der schaue sich mal APL an. Das ist maximal kurz und hat hunderte Regeln. Und führt zu i.d.R. unverständlichen Programmen. Obj-C 1.0 war für mich der schönste Gegenentwurf zu APL.
  • hns schrieb:

    MCDan schrieb:

    D.h.

    Quellcode

    1. self.selectedNetwork = self.scanResults[index];

    würde jetzt auch funktionieren?

    Hm, da weiss ich noch nicht, ob mir dies wirklich gefällt.

    Dann könnten wir ja gleich Obj-C++ nehmen... Und was spart es groß gegenüber:

    Quellcode

    1. [NSArray arrayWIthObjects:@"1", other, nil];
    . Spart Tipparbeit - aber ist wieder eine Abkürzung die der Lesende (!) kennen muß.

    Mir gefällt das alles nicht. Ich bin da einfach "Purist" und finde das Obj-C1.0 wunderbar systematisch aufgebaut war. Eben von Mathematikern entwickelt und nicht von der Marketingabteilung. Hinter den Erweiterungen kann ich selten feststellen, dass sie sich ins System einfinden. Viele Köche verderben halt den Brei...

    Warum steht z.B. [] hier für ein Array? Das ist doch eine Anlehnung an C und Java. Und wie wird ein NSDictionary initialisiert? Eventuell @{} ? Wäre naheliegend. Aber warum dann @{} für Arrays und nicht @()? Das würde dann wenigstens zu den ASCII-Property-Lists passen. Das wäre z.B. eine tolle Sache, wenn man ganze PLists in den Source kopieren könnte.

    Ach geht ja schon: [@"(hier, dort)" propertyList];

    Also in Summe bin ich der Meinung: eine Programmiersprache ist umso leichter zu lesen und zu verstehen, um so weniger Regeln sie hat. Dadurch wird der Text manchmal etwas weitschweifiger und länger was nicht schlimm ist.
    Wer das nicht glaubt, der schaue sich mal APL an. Das ist maximal kurz und hat hunderte Regeln. Und führt zu i.d.R. unverständlichen Programmen. Obj-C 1.0 war für mich der schönste Gegenentwurf zu APL.


    :thumbsup:
  • McPringle schrieb:

    Zum Thema "Getter für eigene Instanzvariablen nutzen": Wenn in einer Klasse auch für den Zugriff auf Instanzvariablen Getter benutzt werden, hat das den unschlagbaren Vorteil, dass die Instanzvariable im Zuge der Evolution der Klasse jederzeit entfallen kann, sofern der Getter noch das erwartete liefert – ohne Modifikationen ausserhalb des Getters! Würde direkt auf die Instanzvariable zugegriffen werden, müsste in diesem Fall jeder einzelne Aufruf angepasst werden: Mühselig!

    McPringle

    Wenn eine Instanzvariable entfallen kann, weshalb will ich dann weiterhin intern auf ihren Setter zugreifen müssen?
    Sie kann ja nur deshalb entfallen, weil sie unnötig geworden ist. Im Sinne der Lesbarkeit gehören dann sämtliche verwirrenden Altlasten ebenfalls entfernt.
    Da liegt doch ein Fehler in der Planung. :P

    Markus Müller schrieb:

    Auch innerhalb der Klasse ist es nicht verkehrt, accessoren zu benutzen (Stichwort KVO). Was den zusätzlichen Methodenaufruf betrifft: POITROAE!!!einself11!!!

    Was KVO betrifft: POITROAE!!!einhundertundelf!1!!!
    Oder auch: wenn ich es wirklich mal brauche, kann ich es auch schnell nachpflegen. ;)

    Thallius schrieb:

    Hat mich immer genervt, dass ich für sowas einfaches wie einen Eintrag aus einem Array zu bekommen eine ellenlange Methode objectAtIndex: aufrufen muss.

    Macht doch was ihr wollt, ich bleibe meinen eckigen Klammern und ellenlangen Methodennamen treu. ^^

    hns
    :thumbsup:
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Thallius schrieb:


    gerade das finde ich genial. Hat mich immer genervt, dass ich für sowas einfaches wie einen Eintrag aus einem Array zu bekommen eine ellenlange Methode objectAtIndex: aufrufen muss.
    Anscheinend schreibst Du Software nur für den Compiler... Und nicht für die Nachwelt :) Denn mit Autocompletion brauche ich nur "ob" und Tab drücken. Und ich kann das Ergebnis in 2 Jahren meiner Frau geben und sie versteht was das tut. Es steht ja wörtlich da: "object At Index:5".
  • hns schrieb:

    Thallius schrieb:


    gerade das finde ich genial. Hat mich immer genervt, dass ich für sowas einfaches wie einen Eintrag aus einem Array zu bekommen eine ellenlange Methode objectAtIndex: aufrufen muss.
    Anscheinend schreibst Du Software nur für den Compiler... Und nicht für die Nachwelt :) Denn mit Autocompletion brauche ich nur "ob" und Tab drücken. Und ich kann das Ergebnis in 2 Jahren meiner Frau geben und sie versteht was das tut. Es steht ja wörtlich da: "object At Index:5".

    Ich bin mir gerade nicht sicher ob meine Frau das verstehen muss. Sorry aber wenn du so argumentierst, dann müßtest man auch schreiben

    Quellcode

    1. locale variable integer a;
    2. setVar(a,1);
    3. if(CompareIsEqual(a,1))...




    etc. Es gibt so viele Axiome der Programmierens die Du als normal hinnimmst wie eben a=a+1; (Was rein mathematisch und eben auch logisch total schwachfug ist) oder if(a==1) was auch nicht besser aussieht. Dazu gehört für mich eben auch das [] ein Index in einem Array ist.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Deine Frau wird sicherlich in der Lage sein den Zuweisungsoperatoren = aus anderen Ebenen herleiten zu können.
    setVar(a,9) ist also unsinnig, da a = 9 bekannt sein dürfte.

    Sicherlich mag a == 9 verwirrend sein, da wäre eine gewisse Logik, die Zuweisungen in If-Abfragen, while-/for-Schleifen etc verbietet und ein if(a = 9) entsprechend ermöglicht durchaus klug.
    Leider liegt C zu Grunde, und da ist das eben so.

    Ja, a = a+1 mag unsinnig erscheinen. Ebenso wie a += 1.
    Nur reden wir hier nicht von C.
    Wir reden von Objective-C.

    Und du willst hässliche C-Skalare-Angewohnheiten auf hübsche Objective-C-Objekte anwenden.
    Pfuibäh.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P