Re: Übersetzung und Bedeutung von "Out Of Scope"

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hallo Alexander,

ich kann zwar Out Of Scope mit "Außer Sichtweite" übersetzen, aber die
wirkliche Bedeutung ist mir noch nicht klar. Kann vielleicht auch jemand
mal sagen, wie man das ins IT-Deutsch übersetzt? Oder sagt man "(...)
geht Out Of Scope"?

'Sichtweite' oder 'Sichtbarkeit' ist in der Bedeutung auch ein Nuance
unterschiedlich,
verglichen mit 'Gültigkeitsbereich'.

Wenn Du z.B. ein Modulvariable V und ein Prozedurvariable V hast, sind in
der
Prozedur beide im Gültigkeitsbereich, aber die Modulvariable ist nicht
sichtbar;
wenn sie Private ist, ist sie in VB sogar wirklich nicht erreichbar
(Zugriff
über 'Me' geht ja nur für Public-deklarierte Members).

Zum einen käme ich darum im Normalfall auch nie auf die Idee, einer
Modulvariablen und einer Prozedurvariablen den gleichen Namen zu geben.

Du kommst nicht auf die Idee, weil Du dann ein Problem hättest, wenn
auch ein leicht lösbares ;-)

Sagen wir es so: Ich käme nicht *mehr* auf die Idee, da ich die damit verbundenen Probleme zur Genüge kenne und keinen Grund sehe, ohne Not Probleme zu schaffen, egal wie leicht sie zu lösen wären.

Schon in VB-7 gibt es aber geeignete Mittel zum Sichtbarmachen durch
Namenskonflikte verdeckter 'Objekte'.
Es übrigens ist auch durchaus verbreitet und praktisch, steigert Lesbarkeit
und Verständnis, z.B. für die Formalparameter im Konstruktor dieselben Bezeichner
zu verwenden wie für private Modul/Klassen-Daten, denen die Werte der Aktualparameter
dann zugewiesen werden.

Class Person 'VB.Net-code
Private Name As String
Private Age As Integer

Sub New (Name As String, Age As Integer)
Me.Name = Name
Me.Age = Age
End Sub

1.) Das "Me." kannst Du auch weglassen. Sowohl funktional als auch bezüglich der Lesbarkeit und des Verständnisses bringt es gar nichts. Im Gegenteil: Üblicherweise würde ein Zugriff über die Me.-Qualifizierung bedeuten, dass man auf eine Methode zugreifen will.

2.) Ich gehe mal davon aus, dass die zugehörigen Eigeschaftenmethoden dann auch sinnvollerweise "Name" und "Age" heißen sollten, oder? Allerdings würde das dann nicht funktionieren, wenn schon Variablen die gleichen Namen haben, egal ob sie privat oder öffentlich sind. Der Compiler würde schlicht streiken, da er nicht wüsste, ob mit Me.Name die private Variable oder die Eigenschaftenmethode gemeint ist. Und damit hättest Du auch ein Problem, aber ein nicht lösbares.

3.) Verbreitet und praktisch und in der zumindest mir bekannten allgemeinen Literatur zur Programmierung unter VB und VB.NET ist dagegen, private Variablen mit einem Prefix zu versehen, um solche Probleme garnicht erst aufkommen zu lassen:

Private mName As String
Private mAge As Integer

Sub New (Name As String, Age As Integer)
mName = Name
mAge = Age
End Sub

Dem Verständnis und der Lesbarkeit täte das keinen Abbruch - im Gegenteil. Und die Eigenschaftenmethode zum Auslesen des Namens brächte auch keinerlei Komplikationen mit sich:

Public ReadOnly Property Name() As String
Get
Return mName
End Get
End Property

Zum anderen ist Sichtbarkeit und Gültigkeit doch dasselbe:

Klares Nope. Das wird in allgemeiner Literatur zur Programmierung
sinnvollerweise unterschieden Und auch in VB-6 gibt es Situationen,
in den eine gültige Variable 'verdeckt', d.h unsichtbar wird und durch
explizitere, vollqualifizierte Syntax wieder sichtbar gemacht werden kann.
Das Modulscope/Procedurescope-Bsp ist nicht das einzige. Und nein, das
ist auch nicht rein akademisch.

Doch, es ist akademisch. Zum einen ist "allgemeine Literatur zur Programmierung" nicht immer im Detail relevant für VB6. Zum anderen wüsste ich keine Situation in VB6, in der es sinnvoll wäre, sich das Problem "verdeckter" Variablen überhaupt erst zu schaffen.

Eine in einem
Bereich nicht sichtbare und nicht erreichbare Variable ist für diesen
Bereich auch nicht gültig, ganz einfach.

Ich würde sagen 'vereinfacht' und leider auch unrichtig.
Eine Modulvariable ist immer im ganzen Modul gültig (Punkt!).

Ok, akademisch gesehen hast Du Recht.

Das Problem im Beispiel ist eben die Sichtbarkeit der verdeckten Variable.
Woraus der Unterschied auch _eigentlich_ auch ersichtlich werden
sollte.

Wäre dieselben Modulvariable wie gesagt Public deklariert, könnte sie wie gesagt
auch zugreifbar gemacht werden - wobei sich bezogen auf das Modul nichts an ihrem
Gültigkeitsbereich änderte, wohl aber an ihrer Sichtbarkeit -; und zwar in einem
Objektmodul über Me.VariablenName, in einem Standard-Modul über ModulName.VariablenName.

Sicher könnte sie als Public deklariert werden. Aber warum sollte man das machen? Üblicherweise sollte der Zugriff von außen über Eigenschaftenmethoden erfolgen.

Denn in Deinem Beispiel ist ja
dann eben die andere Variable gültig, die sichtbare.

Was - unzutreffenderweise - impliziert bzw suggeriert, dass es nur eine gültige Variable
desselben Namens innerhalb desselben Gültigkeitsbereichs geben kann, was selbst in VB-6 so
nicht stimmt.

Ein zweites Beispiel sind öffentliche und damit globale Variablen/Methoden in Modulen, die
können auch denselben Namen haben, was IRL auch vorkommt, wenn bspw mehrere Leute an
dem selben Projekt arbeiten.

Sicher kann das vorkommen. Aber bezüglich globaler Variablen und Module gibt es bereits in VB6 die Namespace-ähnliche Möglichkeit, den Modulnamen als Qualifizierer voranzustellen und so gezielt die richtige Variable zu erwischen. Die globalen Variablen sind überall sichtbar und überall gültig. Daher sehe ich nicht, inwiefern dieser Punkt ein Beispiel für einen Unterschied zwischen "Sichtbarkeit" und "Gültigkeit" sein sollte.

Drittes Beispiel sind z.B. importierte Bezeichner (Enums, Consts) aus Typelibs, auch die
kollidieren IRL häufig mit Bezeichnern des Programmierers. Auch in so einem
Fall sind dann beide Bezeichner gültig, ohne weitere Spezifikation über voll-qualifizierten
Zugriffs aber nur der eine sichtbar.

Nicht zuletzt, gibt es, um das Problem der Sichtbarkeit und Namenskonflikten besser zu
lösen daher ja auch Namensräume, oder andere syntaktische Mittel um jeden gültigen Bezeichner
unter allen Umständen sichtbar machen zu können. Wenn auch noch nicht in VB anno 98,
aber in allen (oder sagen wir den meisten) mir bekannten heutigen Umgebungen zur
Anwendungsentwicklung.

Ok, akademisch betrachtet hast Du Recht.


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

.

Relevant Pages

  • =?ISO-8859-15?Q?Re:_=DCbersetzung_und_Bedeutung_von_=22Out_Of_Scope=22?=
    ... Private m_Name As String ... Public Sub New(ByVal Name As String, ByVal Age As Integer) ...
    (microsoft.public.de.vb)
  • Re: Per VBA mit Nicht-Standard-Drucker ausdrucken
    ... Determine Available PaperBins with DeviceCapabilities API ... Private Declare Function OpenPrinter Lib "winspool.drv" Alias _ ... DeviceCapabilities function requires a printer name and port. ...
    (microsoft.public.de.word.vba)
  • How do I add/delete row into/from a DataGridView
    ... So now in the area named Data Source on my screen I can see Person with its ... Person as a DataGridView into my Form. ... by writing a Age, Name and Person_number? ... private string person_number; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Private variables question
    ... Although I have given up on using prefixes unless it is an underscore for private fields, and that only because Delphi is not case-sensitive. ... private string name; ... private int age; ...
    (borland.public.delphi.non-technical)
  • Re: WPF und datenbindung an objekt collektion ?
    ... Private ser As New XmlSerializer)) ... End Sub ... Private _name As String ... Public Property NameAs String ...
    (microsoft.public.de.german.entwickler.dotnet.vb)