Warum dürfen lokale und Membervariablen den gleichen Namen haben?

EOP

NeeLa schrieb:

Ich seh schon, "Ergen Omut Pockmann", kurz EOP. Leidenschaftlicher VB.NET Programmierer. Bezahlt seinen Senf seit der Beta von .NET bis dato mit VB. In seiner Freizeit streicht er nicht nur Senf auf seine Brötchen, gerne gibt er seinen Senf auch in Forumbeiträgen dazu _Kostenlos ..

Das war dann mal mein Senf.

Selten so einen schwachsinnigen post gelesen.
Dagegen sind sogar meine top-notch.

NeeLa

Achso klar, wenn wir schon schwachsinnig sind:

Vorher Fenster öffnen nicht vergessen - du könntest dir sonst weh tun.

Ich denke aber "absolut sinnlos" trifft es viel besser, oder was war deine Intention mit diesem Kommentar?

Aber heeey,

Dagegen sind sogar meine top-notch.

vor allem wenn jemand Ironie in vollem Maße benutzt, aber scheinbar nicht mal ansatzweise dazu in der Lage ist sarkasmus zu verstehen.

Mechanics

@NeeLa: lass bitte diese Diskussionen, EOP ist halt so. Gewöhn dich dran, der Umgangston in dem Forum kann recht locker sein, man muss nicht auf alles angehen. Außerdem fand ich als unbeteiligter seinen Kommentar auch lustiger

hustbaer

Ja ja schrieb:

PS: Bezüglich Namenskonvention: Viel Spaß, wenn du mal gezwungen bist, VB.NET zu programmieren und ein Public Property hast sowie Funktionen, wo ein gleichnamiger Parameter vorkommt (z.B. ein Konstruktor, der alle wesentlichen Propertys setzt). Da nützt dir die Tatsache, dass dein Property großgeschrieben und dein Parameter kleingeschrieben ist, gar nichts.

Ist VB.NET alles ernstes immer noch case-insensitive?
Ist aber eigentlich auch egal. Wenn das so ist, dann muss man in VB einfach andere naming conventions verwenden.

hustbaer

@Mechanics
EOP sowie 1-2 andere nerven schon gewaltig. Ich verstehe nicht wieso man das gut heissen sollte. Nur weil die meisten aufgegeben haben (inklusive der Moderatoren) heisst das ja nicht dass es gut so ist.

NeeLa

Naja, die Datenbank kann den Platz für meinen Account jetzt jedenfalls anderweitig verwenden. Ich kann dafür leider kein Verständnis aufbringen.
Ich möchte mich an dieser Stelle nur noch bei den Moderatoren für die nicht passenden Beiträge zu diesem Thread entschuldigen.

Viel Spaß weiterhin mit dem Forum!

EOP

hustbaer schrieb:

@Mechanics
EOP sowie 1-2 andere nerven schon gewaltig. Ich verstehe nicht wieso man das gut heissen sollte. Nur weil die meisten aufgegeben haben (inklusive der Moderatoren) heisst das ja nicht dass es gut so ist.

Ceterum censeo Carthaginem esse delendam. :p

NeeLa schrieb:

Naja, die Datenbank kann den Platz für meinen Account jetzt jedenfalls anderweitig verwenden. Ich kann dafür leider kein Verständnis aufbringen.
Ich möchte mich an dieser Stelle nur noch bei den Moderatoren für die nicht passenden Beiträge zu diesem Thread entschuldigen.

Viel Spaß weiterhin mit dem Forum!

Na dann heul doch.

@hustbaer:
Bei vBullettin gab es eine praktische Option: "ignore this member"
Musst du bei phpBB eben brain-technisch implementieren.

So, nach den Off-Topic-Diskussionen, wie sieht's denn nun mit meiner ursprünglichen Frage aus?

Hätte es Probleme geben können, wenn man in einer Programmiersprache von vornherein verbietet, dass lokale Variablen in Memberfunktionen einer Klasse und die Membervariablen dieser Klasse nicht denselben Namen haben dürfen?

Wie gesagt, in Bezug auf globale Variablen oder Konstanten ist mir das klar:
Wenn ich eine Bibliothek verwende und der Schreiber der Bibliothek irgendwann eine Konstante einbaut, die denselben Namen hat wie irgendein Member in meiner Klasse, dann haben wir ein Problem. Der Schreiber der Bibliothek kennt meine Klasse nicht, kann also nichts dafür. Seine Bibliothek kompiliert. Aber mein Code kompiliert jetzt nicht mehr.

Dieses Phänomen trifft jedoch nicht auf Variablen innerhalb einer Klasse zu:
Wenn ich eine Klasse schreibe und da irgendwelche lokalen Variablen benutze und dann schreibt jemand anderes meine Klasse weiter und führt eine Membervariable mit dem Namen ein, naja, dann muss er sich eben darum kümmern, dass die lokalen Variablen vorher erstmal alle umbenannt werden bzw. den Namen seiner Membervariable ändern.
Aber die Situation, dass er eine Änderung an der Klasse durchführt, die bei ihm gar kein Problem macht, sondern erst bei mir nicht mehr kompiliert, das geht eben nicht. Denn die Klasse ist ja ein Ganzes und muss auch als Ganzes kompiliert werden. Eine Situation wie oben mit der globalen Variable ist hier also meines Wissens nach nicht möglich. Der Bearbeiter einer Klasse hat immer Zugriff auf alle Teile der Klasse.

Deshalb nochmal die Frage: Gäbe es trotzdem ein Problem, wenn man von Anfang an die gleiche Benennung von lokalen und Membervariablen einer Klasse verbieten würde?

SeppJ

Ja ja schrieb:

Deshalb nochmal die Frage: Gäbe es trotzdem ein Problem, wenn man von Anfang an die gleiche Benennung von lokalen und Membervariablen einer Klasse verbieten würde?

Warum sollte man etwas ohne Grund verbieten? Man könnte auch verbieten, dass Bezeichner mit 'i' losgehen, damit man es nicht mit int verwechseln kann.

hustbaer

@Ja ja
Das Problem tritt genau so bei Membervariablen auf, und zwar bei Membervariablen von Basisklassen.
Lösen könnte man das lediglich dadurch dass Membervariablen immer irgendwie qualifiziert werden müssen (bzw. theoretisch auch dadurch dass lokale Variablen immer qualifiziert werden müssen, was aber wohl die umständlichere Variante wäre).

@SeppJ
Ist ja nicht ohne Grund. Es ist ne potentielle Fehlerquelle.
Man kann jetzt unterschiedlicher Meinung darüber sein wie schlimm diese ist. Aber dass grundsätzlich die Gefahr besteht, dass es zu Verwechslungen kommt, ist mMn. klar.

hustbaer

EOP schrieb:

@hustbaer:
Bei vBullettin gab es eine praktische Option: "ignore this member"
Musst du bei phpBB eben brain-technisch implementieren.

Du könntest auch einfach deine sinnlosen Beiträge einstellen. Wäre für alle Beteiligten weniger Arbeit (sogar für dich, musst dann ja weniger tippen).

rapso

Ja ja schrieb:

Hätte es Probleme geben können, wenn man in einer Programmiersprache von vornherein verbietet, dass lokale Variablen in Memberfunktionen einer Klasse und die Membervariablen dieser Klasse nicht denselben Namen haben dürfen?

die philosophie hinter c bzw c++ war immer dass dem programmierer die entscheidungsfreiheit gegeben wird was und wie er es machen moechte.
Ich denke das ist worauf Stroustrup abzielt:
www.stroustrup.com/bs_faq.html#multiparadigm

das hat natuerlich auch nachteile und es gibt sprachen die damit werben programmieren zu helfen indem sie ihnen freiheiten nehmen. manche schreiben styles vor, manche limitieren speicherverwaltung, manche threading etc.

ich denke c++ ist so erfolgreich, weil es jedem die freiheit gibt seine eigenen limitierungen zu machen. ich hab in firmen gearbeitet wo die styleguide festgelegt hat, dass member immer mit m_ als prefix anfangen muessen, schon ist das problem gegessen. andere firmen schrieben vor dass member uppercase und parameter und local variables mit lower case anfangen. meine aktuelle firme schreibt vor dass alle variablen grundsaetzlich mit lower case anfangen, falls du mal das missgeschick hast dass eine lokale variable die member ueberdeckt, kannst du immer noch mit this-> drauf zugreifen. du kannst aber auch lustige optimierungen machen ala

const auto Foo = this->Foo

und der rest funzt.
ist geschmackssache, wieso sollte man das verbieten? wenn es gefaehrlich ist, kann der compiler dir eine warming ausgeben. du solltest das mit einem pragma triggern koennen.

Wenn ich eine Klasse schreibe und da irgendwelche lokalen Variablen benutze und dann schreibt jemand anderes meine Klasse weiter und führt eine Membervariable mit dem Namen ein, naja, dann muss er sich eben darum kümmern, dass die lokalen Variablen vorher erstmal alle umbenannt werden bzw. den Namen seiner Membervariable ändern.

styleguide die das ausschliesst und du musst keinen gedanken mehr dran verschwenden.

Deshalb nochmal die Frage: Gäbe es trotzdem ein Problem, wenn man von Anfang an die gleiche Benennung von lokalen und Membervariablen einer Klasse verbieten würde?

gibt immer leute die das eine oder das andere als problem sehen. du koenntest verbieten dass lokale variablen mit lower case anfangen und member variablen mit upper case (so wie es verboten ist dass variablen mit zahlen anfangen).
du koenntest sehr viel mehr verbieten, z.b. implizites casten (in java kannst du z.B. nicht if(vector.size()) schreiben weil es fehler verursachen koennte). du koenntest integer integer divisions verbieten weil es nicht selten zu fehlern fuehren kann (pascal hat deswegen ein 'div' wenn ich mich recht entsinne). du koenntest operator overloading verbieten/weglassen, weil damit implizite funktionalitaet suggeriert wird die anders sein kann je nach user (z.b. Vector*Vector koennte mul, dot, cross sein).

hustbaer schrieb:

@Ja ja
Das Problem tritt genau so bei Membervariablen auf, und zwar bei Membervariablen von Basisklassen.

OK, dass das bei Ableitungen ein Problem sein kann, leuchtet mir ein.

Allerdings: Bei Ableitungen müsste man ohnehin liberaler sein, so wie es ja jetzt auch schon der Fall ist:
Man kann innerhalb einer Klasse nicht zweimal den gleichen Membervariablennamen haben, aber sehr wohl ist es möglich, dass eine abgeleitete Klasse eine Variable mit demselben Namen wie die Basisklasse hat.

Das heißt, würde man den Vorschlag, den ich genannt habe, einbauen, würde er sich sowieso nur auf Eindeutigkeit innerhalb derselben Klasse beziehen.
Zwischen Basis und Ableitung bestünde das Problem weiterhin, aber genauso, wie ja ohnehin auch das Problem besteht, dass eine abgeleitete Klasse einen gleichnamigen Member wie die Basisklasse deklarieren kann.

In der Praxis wäre das ganze aber schon noch ausreichend. Denn während es ja ohnehin schlechter Stil ist, Membervariablen public oder protected zu machen, ist das Problem mit der Gleichbenennung von Membervariablen und Funktionsparametern durchaus real. (Zumindest hab ich noch nie gesehen, dass zum Beispiel in Java jemand wirklich m_ bzw. _ vor die Member schreibt. Das scheint nur bei C++- und C#-Programmierern üblich zu sein.)

Daher die Abwandlung meiner Frage: Gibt es einen reellen Grund, die Gleichbenennung innerhalb derselben Klasse zu erlauben (Vererbung jetzt mal außen vor gelassen, wo es ohnehin liberalere Regeln für die Benennung gibt als nur innerhalb einer Klasse) oder hätte man das ohne Probleme verbieten können?

hustbaer

Ja ja schrieb:

Daher die Abwandlung meiner Frage: Gibt es einen reellen Grund, die Gleichbenennung innerhalb derselben Klasse zu erlauben (...)

Ich denke wurde schon alles gesagt was es zu sagen gibt. Es gibt keinen technischen Grund. Was Leute allerdings als "reellen" Grund ansehen ist wohl sehr subjektiv.

Shade Of Mine

hustbaer schrieb:

Ja ja schrieb:

Daher die Abwandlung meiner Frage: Gibt es einen reellen Grund, die Gleichbenennung innerhalb derselben Klasse zu erlauben (...)

Ich denke wurde schon alles gesagt was es zu sagen gibt. Es gibt keinen technischen Grund. Was Leute allerdings als "reellen" Grund ansehen ist wohl sehr subjektiv.

Der technische Grund, der ja schon genannt wurde, ist ja ein echter technischer: Wenn ich eine Variable in einem Scope einführe, geht plötzlich an einer komplett anderen Stelle die mit meiner Änderung nichts zu tun hat plötzlich Code hops.

Ich führe einen private Member in einer Basisklasse ein und eine Funktion einer abgeleiteten Klasse hat plötzlich compile Fehler. Wir bringen somit eine Enge Bindung zwischen unabhängigen Scopes ins Spiel. Das ist ein technisches No Go.

hustbaer

Manchmal glaube ich dass ich z.T. absichtlich falsch verstanden werde.
Ich denke es ist klar dass mir das bewusst ist, und dass ich es eben nicht als technischen Grund bezeichnen würde.

Der Compiler kann das Problem erkenne und melden. Der Programmierer kann es beheben. Danach funktioniert wieder alles wie erwartet.