Properties und Getters

[Marky]

Wer sagt denn dass Datenkapselung syntaktische Unterstützung braucht? Datenkapselung in Python kannst du ja auch implizit sehen, so wie Interfaces auch. Dir werden eben weniger Hürden vor die Beine geworfen um die Datenkapselung aufzubrechen. In Java könntest du über Reflection die Kapselung überwinden, in Python über den Zugriff auf Attribute die mit ``_`` beginnen.

Das sagt niemand, nur finde ich syntaktische Unterstützung nicht verwerflich und sie zu nutzen auch nicht. Wenn alles nur aus Konventionen besteht, dann ist es leichter diese zu verletzen, als wenn man die syntaktisch Hürde überwinden muss. Ich meine, eine gewisse Hürde gibts ja in Python auch, nur verstehe ich eben solche Aussagen nicht, dass man das nicht oder kaum braucht usw ... Das ist ja dann eine Frage des Programmierstils und nicht unbedingt eine Frage guten Designs.
Es ist sicherlich viel Ansichtssache bei dem Thema, aber in Java kann ich auch alles public machen ... Es ist nur eben die Frage, ob das OO-technisch dann noch Sinn macht.
Und was die minimalen Hürden betrifft, die Kapselung zu verletzen, so ist das doch auch Ansichtssache. Es kann ja jeder so coden wie er möchte, nur finde ich, dass es mind. genausoviel Sinn macht, die Möglichkeit zu nutzen, per Codierung (Syntax) klar zu machen, dass keiner in die Internas greifen soll, als es durch Konvention festzulegen. Hoffentlich hält sich dann jeder dran.
Wenn ich ein Tür abschließe, dann kann ich die auch mit Gewalt öffnen, nur wenn sie abgeschlossen ist, kann eben nicht jeder Heini rein, der gerade mal zufällig davorsteht, und noch nicht mal weiß, was er da überhaupt soll.

Man kann doch nicht immer davon ausgehen, dass der Entwickler der Software zeit seines Lebens der einzige ist, der an dem Programm arbeitet und damit genau weiß, was er tunlichst unterlassen sollte.

[Darii]

Es ist sicherlich viel Ansichtssache bei dem Thema, aber in Java kann ich auch alles public machen ... Es ist nur eben die Frage, ob das OO-technisch dann noch Sinn macht.

Das kann man in Java eben nicht so einfach. In Python ist es kein Problem die Funktionsweise von Attributen zu ändern ohne das Interface zu verändern. Das geht in Java nicht.

Code: Alles auswählen

class Person:
    name = "Hans Mustermann"

p = Person()
p.name = "Max Müller"

# nun möchte man beim setzen des Attributs noch etwas machen

class Person:
    _name = "Hans Mustermann"

    @property
    def name(self):
        return self._name
    
    @name.setter
    def name(self, name)
        self._name = name
        self.anrede = "Herr"

# Das Interface nach außen ist gleich geblieben
# In Java müsste man name private machen und
# getter und setter einführen, das würde das Interface
# aber ändern.
p = Person()
p.name = "Max Müller"

nur finde ich, dass es mind. genausoviel Sinn macht, die Möglichkeit zu nutzen, per Codierung (Syntax) klar zu machen, dass keiner in die Internas greifen soll, als es durch Konvention festzulegen. Hoffentlich hält sich dann jeder dran.

Dagegen spricht ja auch nichts es geht den meisten auch nur damit, dass man nicht alles private machen muss "weil sich das halt so gehört" bei einem, von trivialen gettern hat auch niemand was.

[Leonidas]

Das sagt niemand, nur finde ich syntaktische Unterstützung nicht verwerflich und sie zu nutzen auch nicht.

Ja, stimmt. Gibt es aber nicht, also kann es wohl nicht verwerflich sein sie nicht zu nutzen, weil es gar nicht möglich ist in Python.

Wenn alles nur aus Konventionen besteht, dann ist es leichter diese zu verletzen, als wenn man die syntaktisch Hürde überwinden muss. Ich meine, eine gewisse Hürde gibts ja in Python auch, nur verstehe ich eben solche Aussagen nicht, dass man das nicht oder kaum braucht usw ...

Du meinst den Bodenstrich? Ja, ist eine kleine Hürde, aber wenn man Python programmiert, dann weiß man dass man ``_``-Attribute nur anfasst, wenn man weiß was man will. Es ist nun mal vieles simpler gemacht und so gesehen ist es auch nicht schwer in Java in der IDE einen Menüpunkt anzuklicken "hol mir das Attribut via Reflection".

Es ist sicherlich viel Ansichtssache bei dem Thema, aber in Java kann ich auch alles public machen ... Es ist nur eben die Frage, ob das OO-technisch dann noch Sinn macht.

In Java ist das nicht so üblich, aber angenommen das wäre so, dann würden sich die meisten Leute dabei doch auch nichts denken "ist halt so", ggf sogar "OOP ist eben so". Es hängt wohl ab, was man selbst gewöhnt ist und erwartet.

Ich habe vor paar Tagen dieses hübsche Zitat in comp.lang.python gefunden:

> Python *is* object-oriented, but it is not (as your definition suggests)
> object-fascist.  

I'd put it more mildly. Python is object oriented. The orientation is
there but the fanatism is gone.

Letztendlich ist der Mechanismus dass alles public ist in meinen Augen genauso gangbar. Bei realen Objekten ist es auch so dass man auf interna zugreifen muss, also ggf. das Auto zerlegt und womöglich kaputtmacht. Man muss eben selbst wissen, in wie weit man gehen will. So gesehen ist ``private`` genauso eine Konvention wie ``_``, in Java ist sie syntaktisch, in Python eher semantisch.

Es kann ja jeder so coden wie er möchte, nur finde ich, dass es mind. genausoviel Sinn macht, die Möglichkeit zu nutzen, per Codierung (Syntax) klar zu machen, dass keiner in die Internas greifen soll, als es durch Konvention festzulegen. Hoffentlich hält sich dann jeder dran.

Wenn er sich nicht dran hält, dann ist das sein Problem. Der Bodenstrich hat sich in der Community durchgesetzt, und wenn sich jemand nicht daran halten will ist das seine Entscheidung. Da muss man ihm nicht zusätzlich Steine in den Weg werfen.

Wenn ich ein Tür abschließe, dann kann ich die auch mit Gewalt öffnen, nur wenn sie abgeschlossen ist, kann eben nicht jeder Heini rein, der gerade mal zufällig davorsteht, und noch nicht mal weiß, was er da überhaupt soll.

``Tür._aufbrechen`` ist von der Sicherheit genauso wie ``private void aufbrechen``. Der Unterschied ist eigentlich nur die Einstellung des Programmierers. In Java versucht man die Programmierer vor sich selbst zu schützen, in Python geht man vom mündigen Programmierer aus.

Bei uns vor dem Haus steht am Gehweg eine Schneeschaufel, den ganzen Winter über. Wenn jemand sie mitnehmen will, ist sie völlig ungeschützt gegen Diebstahl, lediglich über die Soziale Konvention, dass man fremde Sachen nicht einfach mitnimmt. Natürlich, man könnte sie anketten oder ins Haus tragen, aber es funktioniert so auch.

Bei den Attributen ist es noch besser, denn wenn jemand auf ``private`` Attribute zugreift ist das sein Problem, nicht meines. Ich habe gesagt auf was er zugreifen kann, wenn er darüber hinausgeht, nicht mein Problem. Also wie im Straßenverkehr. Wenn jemand mit seinem Porsche mit 100 durch die Stadt fährt, ist nicht der Hersteller daran schuld. Und eine auf technischem Wege erzwungene Geschwindigkeitsbegrenzung würde wohl auf Protest vieler Autofahrer stoßen.

'Tschuldige für die vielen mäßig passenden Vergleiche (das ist immer so das Problem). Vielleicht wirst du dann meinen Standpunkt verstehen - wenn nicht, dann ignorier sie einfach.

Man kann doch nicht immer davon ausgehen, dass der Entwickler der Software zeit seines Lebens der einzige ist, der an dem Programm arbeitet und damit genau weiß, was er tunlichst unterlassen sollte.

Ganz recht. Dafür gibt es ja sowohl in Python wie auch in anderen Sprachen Dokumentation, die über ein einfaches ``private``/``publich`` Schwarzweißsehen hinausgeht und erklärt wie man die API richtig nutzt (und Kommentare sowie ggf. noch andere Dokumente erklären die Implementierung).

[BlackJack]

Wenn man in Java einfach alles ``public`` macht, ist das nicht dasselbe wie in Python, weil man dann ja nicht mehr unterscheiden kann welches ``public`` Attribut man bedenkenlos benutzen darf und welches nicht. Was in Python eben durch den Unterstrich gekennzeichnet ist.

Wer auf Implementierungsdetails nur deswegen nicht zugreift, weil er es nicht machen kann, ist kein besonders guter Programmierer.

Und zumindest IMHO sind Kapselung und Zugriffsschutz zwei orthogonale Konzepte, die man zusammen nutzen kann, aber nicht muss. Solange man öffentliche Schnittstelle und Implementierungsdetails klar unterscheiden kann, braucht man keinen Zugriffsschutz um Kapselung zu betreiben.

Wer Interna verwendet, muss mit den möglichen Konsequenzen leben. Wer Interna nicht verwenden kann, weil Zugriffsschutz im Weg steht, muss unter *den* Konsequenzen manchmal leiden.

[nkoehring]

In Java versucht man die Programmierer vor sich selbst zu schützen, in Python geht man vom mündigen Programmierer aus.

Schoen gesagt

[Marky]

Ja, stimmt. Gibt es aber nicht, also kann es wohl nicht verwerflich sein sie nicht zu nutzen, weil es gar nicht möglich ist in Python.

na ja, die __ Konvention geht ja schon ein wenig über die reine Syntax-Konvention hinaus. Auch wenn das auf Name-mangeling hinausläuft oder wie sich das nennt.
Ein Zugriff von außen mit der Attribut-Bezeichnung von innen ist auf das Objekt-Attribut nicht mehr direkt möglich. Das reicht mir doch schon

In Java versucht man die Programmierer vor sich selbst zu schützen, in Python geht man vom mündigen Programmierer aus.

Schoen gesagt

Finde ich auch

... und ab wann wird/ist man mündig ? Wenn man die Fehler, vor denen einen Java angeblich schützt, nicht mehr macht?

Aber ich denke, ich habe jetzt ein paar Statements gelesen und konnte mir dadurch einen Eindruck zur Meinungsbildung verschaffen.
Schon mal Besten Dank.

Nachtrag:

'Tschuldige für die vielen mäßig passenden Vergleiche (das ist immer so das Problem). Vielleicht wirst du dann meinen Standpunkt verstehen - wenn nicht, dann ignorier sie einfach.

Kein Problem. Es geht mir übrigens nicht darum, Java gegenüber Python in den Himmel zu heben, sondern einfach die (andere) Sichtweise zu verstehen, wenn man mit Python arbeitet.

[Leonidas]

na ja, die __ Konvention geht ja schon ein wenig über die reine Syntax-Konvention hinaus. Auch wenn das auf Name-mangeling hinausläuft oder wie sich das nennt.
Ein Zugriff von außen mit der Attribut-Bezeichnung von innen ist auf das Objekt-Attribut nicht mehr direkt möglich. Das reicht mir doch schon

Achtung, wenn du Name Mangling als "private"-Mechanismus verwendest, wirst du auf Kritik stoßen. Dafür ist es nämlich weniger gedacht. Meist nimmt man für private ``_`` und lässt Mangling Mangling sein.

Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private.

Edit: Schöner Blogpost zu ``__``.

[Marky]

ok. ist "gebookmarked" ...

[bwbg]

Randbemerkung: C++, als typsichere Sprache, bietet ein Brecheisen für private Attribute etc. in ihrer Syntax an. Den allseits beliebten reinterpret_cast<New>(old).

So kann man ganz genüsslich in den Eingeweiden eines Objektes rumwühlen, vorausgesetzt, man kennt die Internas.

Schlussendlich - und das gilt nicht für Programmiersprachen alleine - gibt es keine absolute Sicherheit. Es ist sicherlich etwas gewöhnungsbedürftig, wenn man seitens der Programmiersprache mehr Verantwortung übertragen bekommt und nicht gleich entmündigt wird.

Grüße... Heiko

[Darii]

Naja, dafür ist es ja auch nicht gedacht. Wer z.B. ein Feld "password" private macht nur weil keiner ran soll hat was falsch verstanden.

[bwbg]

Naja, dafür ist es ja auch nicht gedacht. Wer z.B. ein Feld "password" private macht nur weil keiner ran soll hat was falsch verstanden.

Sinnhaftigkeit unterscheidet sich meist sehr oft von Machbarkeit - Mir ging es aber nicht um die Objektsicherheit was die Geheimhaltung des Inhaltes betrifft, sondern vielmehr die Objektsicherheit hinsichtlich der Manipulation von Interna.

Mir (in meiner hobbymäßig, oberflächlichen Beschäftigung mit C++) ist bislang noch kein Anwendungsfall untergekommen, einen reinterpret_cast zu verwenden - dynamic_cast und const_cast (gerade in Verbindung mit C-Libs) schon eher.

Das driftet jetzt aber doch etwas ab...

Grüße... Heiko

[PythonÜbernehmenSie]

Ich möchte mich in die Diskussion als bisher nur passiver Leser auch mal einbringen. Vielleicht teilt ja jemand meine augenscheinliche Vorliebe für klar strukturierte, aber etwas lange Sätze

Zu der Private/Public-Problematik fällt mir ein schönes Zitat ein, das ich in einem anderen Forum gelesen hab:

private schützt vor Murphy, nicht vor Macchiavelli.

Klar ist. dass ich (zumindest in einer Umgebung, die Zeigerarithmetik unterstützt) immer an private Attribute komme, wenn ich es wirklich will. Aber greife ich z.B. in C++ auf eine private Eigenschaft zu, erhalte ich eine Fehlermeldung des Compilers. Durch casten oder Zeigerspielereien komme ich wie gesagt natürlich an die Daten ran, aber da ist ein zunächst einmal gewissser Aufwand dabei. Die Konvention, _ als Präfix für privat gemeinte Attribute zu verwenden, wird dagegen nur durch die Disziplin des Verwenders der Klasse durchgesetzt - ein absichtliches Zugreifen auf ein solches Element ist also als solches erst nach näherer Analyse des Codes und gggf. Konsultation der Dokumentation zu ersehen.

Meiner Ansicht nach sollte eine gute Programmiersprache den Programmierer insofern bevormunden, dass konzeptuell "schlechte" Verhaltensweisen zwar möglich, aber mit höherem Aufwand verbunden sind. Und das Aushebeln der Steuerung, welche Programmteile auf welche Attribute eines Objektes wie zugreifen dürfen und welche nicht, ist meines Erachtens bei einer Sprache, die (u.a.) das objektorientierte Programmierparadigma unterstützt, konzeptionell eher "schlecht".

Als ich mir das erste Mal Python angesehen habe, kam es mir deshalb auch unverständlich vor, dass es für diese Zugriffssteuerung in Python keine Unterstützung seitens der Sprache gibt.

[str1442]

Meiner Ansicht nach sollte eine gute Programmiersprache den Programmierer insofern bevormunden, dass konzeptuell "schlechte" Verhaltensweisen zwar möglich, aber mit höherem Aufwand verbunden sind.

Der höhere Aufwand ist, "_" im Attributsnamen zu sehen und daraufhin die Dokumentation zu konsultieren. Wer das nicht tut, ist selbst schuld wenns richtig kracht.

Wenn es einen höheren Aufwand gibt, dann sollte dieser auch mehr oder weniger klar und einfach sein und nicht aus irgendwelchen Hacks bestehen. Das Benutzen von irgendwelchen Pointer Spielereien oder #define private public kann man wohl kaum als einen "standarisierten" Weg zu beschreiben, oder?

[PythonÜbernehmenSie]

Der höhere Aufwand ist, "_" im Attributsnamen zu sehen und daraufhin die Dokumentation zu konsultieren. Wer das nicht tut, ist selbst schuld wenns richtig kracht.

Die Sache mit _ ist eben keine Eigenschaft der Sprache, sondern eine Konvention, die der Programmierer der Klasse einhält - oder auch nicht. Es ist ein unverbindlicher Vorschlag, mehr nicht. Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten. Also bleibt mir, den Quellcode der Fremdklasse anzusehen - super, ich hab ja sonst nichts besseres zu tun.

Es geht mir nicht zwingend um die Auftrennung in private, protected und public - es geht um Zugriffssteuerung auf Objektklassenebene an sich. Sehr viele Sprachen benutzen dafür eben diese drei (teilweise auch mehr) Sichtbarkeitsbereiche, eventuell kombiniert mit spezifisc hen "Freundschaften", was sicher nicht der Weisheit letzter Schluss ist, aber es funktioniert halbwegs! Python aber verfügt über keinen solchen Mechanismus. Mein Eindruck, der in diesem Thread durchaus bestätigt wird, ist der, dass im Alltag so etwas aber durchaus benötigt wird - deswegen wird der Benennungsvorschlag mit _ empfohlen.

Wenn dieser Mechanismus also in vielen Fällen angebracht ist, warum ihn dann so verwirklichen, dass er ohne den geringsten Aufwand ausgehebelt werden kann? Von diesem Gesichtspunkt aus betrachtet stellt das Fehlen eines solchen Mechanismus eine Designschwäche der Sprache dar, die auf der semantischen Metaebene der Benennung ausgeglichen werden soll.

[Hyperion]

Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten. Also bleibt mir, den Quellcode der Fremdklasse anzusehen - super, ich hab ja sonst nichts besseres zu tun.

Also ich denke man sollte gerade eine gute Dokumentation erwarten können! Was nützt Dir ein Modul ohne Doku? Nichts! Aber das ist doch in jeder Sprache so

Wenn dieser Mechanismus also in vielen Fällen angebracht ist, warum ihn dann so verwirklichen, dass er ohne den geringsten Aufwand ausgehebelt werden kann? Von diesem Gesichtspunkt aus betrachtet stellt das Fehlen eines solchen Mechanismus eine Designschwäche der Sprache dar, die auf der semantischen Metaebene der Benennung ausgeglichen werden soll.

Also ich habe das noch nie benutzt - mag aber sein, dass ich nicht grad nen Python-Gott bin und meine Erfahrung da nicht zählt

[PythonÜbernehmenSie]

[Also ich denke man sollte gerade eine gute Dokumentation erwarten können! Was nützt Dir ein Modul ohne Doku? Nichts! Aber das ist doch in jeder Sprache so

Wenn mir eine für mich neue Klasse bzw. ein neues Modul unter die Hände kommt, kuck ich mir zunächst einmal die öffentlichen "Kommandos" und Attribute an. Sind die aussagekräftig benannt, kann ich mit ihnen zumindest schonmal grundlegend arbeiten, ohne in die Doku zu kucken. Und bevor man bei jedem beliebigen Projekt eine vernünftige Doku erwarten kann, erscheinen GNU/Hurd und Duke Nukem Forever...

Also ich habe das noch nie benutzt - mag aber sein, dass ich nicht grad nen Python-Gott bin und meine Erfahrung da nicht zählt

Meine Python-Kenntnisse sind auch bescheiden, aber ich beziehe mich ja auch die Tatsache, dass andere "gängige" Sprachen so etwas haben, Python aber nicht. Was ja auch ein Teil der Ausgangsfrage ist.

[Hyperion]

Wenn mir eine für mich neue Klasse bzw. ein neues Modul unter die Hände kommt, kuck ich mir zunächst einmal die öffentlichen "Kommandos" und Attribute an. Sind die aussagekräftig benannt, kann ich mit ihnen zumindest schonmal grundlegend arbeiten, ohne in die Doku zu kucken.

ALso nun widersprichst Du Dir aber ein wenig ... vorhin hast Du Dich noch darüber muckiert, in den Quellcode reinzugucken! Nun soll's auf einmal ein gutes Mittel sein ... (was es ja sogar ist - passt halt nur nicht zu Deiner obigen Aussage!)

Und bevor man bei jedem beliebigen Projekt eine vernünftige Doku erwarten kann, erscheinen GNU/Hurd und Duke Nukem Forever...

Also ich nutze nicht jedes beliebige Projekt, sondern eben die, die ich geeignet finde. Für das "geeignet"-Prädikat sind die Doku und ggf. auch Tutorials für mich durchaus eines der wichtigsten Kriterien!

Meine Python-Kenntnisse sind auch bescheiden, aber ich beziehe mich ja auch die Tatsache, dass andere "gängige" Sprachen so etwas haben, Python aber nicht. Was ja auch ein Teil der Ausgangsfrage ist.

Also das ist doch nun irgend wie platt: "Wenn alle aus dem Fenster springen, muss das ja gut sein!" Ok, weniger überspitzt: Python hat ja auch Dinge, die andere Sprachen nicht bieten. Sind die dann in den Punkten auch "schwach" designt? Wenn das so wäre und man diese "MIsstände" beseitigen müßte, würde das schließlich auf eine Universelle Sprache zusteuern ... so eine Art "Volksprogrammiersprache" SCNR

Davon mal abgesehen, dass jede Sprache ihre eigenen Paradigmen hat!

[PythonÜbernehmenSie]

ALso nun widersprichst Du Dir aber ein wenig ... vorhin hast Du Dich noch darüber muckiert, in den Quellcode reinzugucken! Nun soll's auf einmal ein gutes Mittel sein ... (was es ja sogar ist - passt halt nur nicht zu Deiner obigen Aussage!)

Nicht ich kucke in den Quellcode, sondern ein Teil meiner IDE - das Ergebnis bekomme ich dann idealerweise an der Stelle angezeigt, an der ich einen entsprechenden Aufruf oder Zugriff tätigen könnte.

Davon mal abgesehen, dass jede Sprache ihre eigenen Paradigmen hat!

Das würde ich nicht sagen. Ich sage, es gibt eine gewisse Anzahl an Programmierparadigmen, die natürlich recht abstrakt sind. Diese Paraidgmen werden dann in Sprachen auf verschiedene Art und Weise umgesetzt, eine Sprache wie Python setzt dabei mehrere Paradigmen (z.B. objektorienierte, prozedurale, funktionale) um. In dieser Diskussion geht es um das objektorienierte Paradigma. Dieses wird in Python durch den Einsatz von Klassen ermöglicht, in vielen anderen Sprachen (z.B. C++, Java, C#, Ruby) auch. In diesen Sprachen besitzen Klassen vor allem so Elemente wie Attribute, Methoden und Operatoren, Vererbung und eben auch Zugriffsschutz durch Sichtbarkeit. Python verfügt über die ersten drei, aber eben nicht über letzteres.

Soll heißen: Obwohl im Bereich der objektorientierten Programmierung eine starke Gemeinsamkeit mit anderen Sprachen herrscht, fehlt die Sichtbarkeitssteuerung.
Das ist ja zusammengefasst die Ausgangssituation.

Die Frage ist jetzt:
Braucht man diese Sichtbarkeitssteuerung und wenn ja, ist es ein Nachteil, dass Python so etwas nicht hat?

[str1442]

Die Sache mit _ ist eben keine Eigenschaft der Sprache, sondern eine Konvention, die der Programmierer der Klasse einhält - oder auch nicht. Es ist ein unverbindlicher Vorschlag, mehr nicht.

Und in Java, C++ etc pp schreibt sich das "private" magisch vor die Variablen? Die ganze private, protected, public Geschichte ist nichts Essenzielles. Ein Programm funktioniert auch ohne das Zeug recht gut, egal in welcher Sprache. Warum es also "hart" (also syntaktisch) erzwingen? Und auf "_" wird sicherlich in jedem guten Tutorial hingewiesen. Aber ich finde auch Minimalismus toll.

Ich kann mich nicht darauf verlassen, und auch eine (vernünftige) Dokumentation kann ich nicht unbedingt erwarten.

Worauf verlassen? Das das Teil keiner anfassen kann? Wo ist eigentlich das Problem? Wenn jemand das nicht (doppelte Verneinung ) tut, ist das schlicht sein Problem. Entweder er weiß, was er tut, oder es kracht. Und jetzt erklär mir doch bitte noch, warum du in C++ *ohne* Dokumentation mit deinen Pointer Tricks mit pseudoprivaten Variablen besser dran bist als in Python ohne Dokumentation und mit "_".

[Hyperion]

Nicht ich kucke in den Quellcode, sondern ein Teil meiner IDE - das Ergebnis bekomme ich dann idealerweise an der Stelle angezeigt, an der ich einen entsprechenden Aufruf oder Zugriff tätigen könnte.

Ja aber Deine IDE parst ja auch nur den Quelltext. Ob da nun ein "private" oder ein "_" oder eine property geparst wird ist doch dann egal!