Wohin mit den Publics

Eigentlich ist mir die Frage peinlich, aber es kann sonst niemand helfen ... :)

Moderator: Moderatoren

Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Wohin mit den Publics

Beitrag von satmax »

Ganz ohne PUBLIC VARs kommt man ja auch nicht aus. Trotzdem sind sie unschön und fehleranfällig. Wie macht Ihr das?

Ich überlege mir dazu eine Klasse anzulegen. Die Variablen der Klasse kann man dann (tlw.) schützen oder/und in Methoden kapseln.
Gruß
Markus
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Tom »

Was genau meinst Du mit "unschön"? Etwa den mehrfach wiederholten und selten gut begründeten Hinweis, man möge doch bitte auf sie verzichten?

PUBLICs sind PUBLICs. Sie funktionieren m.E. einwandfrei, aber man sollte schon wissen, welche Eigenschaften sie haben. Etwa jene, auch threadübergreifend aktiv zu sein. Das ist ein Vorteil, aber es kann auch ein Nachteil sein. Wenn man etwa irgendwo in einem Thread Einstellungen nachlädt und PUBLICs mit ihnen bestückt, die u.U. gleichzeitig in anderen Threads verwendet werden. Damit kann man sich hübsch selbst die Füße wegschießen. Hiervon abgesehen sind PUBLICs ganz simpel programmglobale Variablen, und das ist in manchen Situationen unverzichtbar. Sie sind nicht von Haus aus besonders anfällig oder so, aber sie sind eben: PUBLICs. :wink:

Und auch "fehleranfällig" ist meiner Erfahrung nach höchstens die Verwendung.
Herzlich,
Tom
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von satmax »

Was genau meinst Du mit "unschön"? Etwa den mehrfach wiederholten und selten gut begründeten Hinweis, man möge doch bitte auf sie verzichten?
Kurz: ja. :wink:

Ich verwende aktuell wirklich sehr wenige, ganz ohne gehts aber nicht. Im Moment werden alle Publics beim Programmstart deklariert. Alle haben das Prefix "public_" und soweit funktioniert das auch. Vielleicht lasse ich es auch so. Ich dachte, mit einer Klasse wäre das eleganter gelöst...
Gruß
Markus
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wohin mit den Publics

Beitrag von AUGE_OHR »

PUBLIC und PRIVATE Memvar sind kein Problem solange man die "überblicken" kann ;)

Ich verwende die "Summer93" ( heisst wirklick so ) Taktik und mache aus einer Memvar eine Function oder ein #xtranslate

in meinen alten S87 Cl*pper Code, wo es noch keine LOCAL gab, hab ich PRIVATE als Variable zum FELD benutzt.
alle Funktionen zu einer Stamm DBF, hab ich unter Cl*pper v5.x, dann in einem PRG zusammengefasst.
nun "könnte" man zwar jeweils eine "Fieldwide" STATIC nehmen ... aber ein Array benötigt weniger Handles

Code: Alles auswählen

#xtranslate mARTNR       => ::Stack\[::SP,1]
#xtranslate mKTKGEGAL    => ::Stack\[::SP,2]
#xtranslate mCODE        => ::Stack\[::SP,3]
#xtranslate mARTIKEL     => ::Stack\[::SP,4]
...
#xtranslate mLastplatz   => ::Stack\[::SP,99]

METHOD ArtClass:init(...)
   ::Stack := {}
   ::SP := 1      // hier nur 1-dim
   ... 
   ::Artnr:dataLink        := VARBLOCK( @mARTNR )
    
RETURN self
ich muss also keine Zeile mit meinen "alten PRIVAT" Variabeln ändern sondern leite diese, mittels #xtranslate, in ein Array Item um.

aber wie komme ich dann "von aussen" ran ...

Code: Alles auswählen

FUNCTION SP_ARTNR(cArtnr)
   IF PCOUNT() > 0
      mArtnr := cArtnr
   ENDIF
RETURN mArtnr
wenn ich die "alte PRIVAT" Variabel von "aussen" erreichen will nutze ich die entsprechende Function um auf das Array Element zuzugreifen.

wie ober erwähnt ist das gezeigte Beipiel für 1-Dim ausgelegt. wenn man nun, unter MDI, "mehrere" Artikel Fenster öffnen will kann man ein n-Dim Array verwenden.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Tom »

PUBLIC und PRIVATE Memvar sind kein Problem solange man die "überblicken" kann
So isses. Allerdings werden PUBLICs und PRIVATEs zur Laufzeit "aufgelöst" und in einer Symboltabelle verwaltet, die man über SymbolInfo() ja auch abrufen kann. Hier gibt es möglicherweise - je nach Nutzung - deutliche Performanceunterschiede zu LOCALs oder Get-Set-Funktionen. Vor allem bei Arrays meine ich, das bemerkt zu haben, aber das kann auch gefühlt gewesen sein. Jedenfalls gibt's bei mir keine PUBLIC Arrays.

Code: Alles auswählen

PUBLIC lPrintPreview := .F.
* wird dann irgendwo geändert und an vielen Stellen abgerufen

Code: Alles auswählen

FUNCTION IsPreview(lSet)
STATIC lIsPreview := .F. (oder .T., je nach Default)
IF PCOUNT()>0
  lIsPreview := lSet
ENDIF
RETURN lIsPreview
Das generiert aber den Overhead, den eine Funktion mit sich bringt. Hat aber den Vorteil, dass es keine PUBLIC gibt, die man u.U. versehentlich in einer XPF-Datei speichert, weil der Filter beim "SAVE TO ALL LIKE ..." falsch ist. :wink:
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von brandelh »

Tom und Jimmy kann ich nur zustimmen, aber deine Frage ob du die Publics in eine Klasse packen sollst, scheint noch offen.

Ich nutze heute keine Publics mehr, wenn ich Variable für das gesamte GUI Programm benötige, dann lege ich iVars im Hauptfenster an.
Wenn diese sich nur auf ein Fenster beziehen, lege ich diese dort an.
Alaska scheint dafür nun ein Applikation Objekt vorzusehen, das ist auch OK.
Einige Sachen speichere ich wie SetAppWindow() oder RootWindow() in statics innerhalb einer Funktion.

Publics sind OK, wenn man sie braucht, im Hauptprogramm anlegt und per MEMVAR sauber deklariert ...
Es muss auf den ersten Blick sichtbar sein, dass es eine Public / Local memvar ist:

M->VarName
pmVarName
lmVarName
...

So verhindert man das größte Problem von Publics: Die Verwechslung / Wechselwirkungen mit anderen Variablen !
Um Wechselwirkungen zu verhindern und Speed zu erhöhen, habe ich alle Publics / Privates abgeschafft - in neuen Programmen !
Gruß
Hubert
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von satmax »

brandelh hat geschrieben:Ich nutze heute keine Publics mehr, wenn ich Variable für das gesamte GUI Programm benötige, dann lege ich iVars im Hauptfenster an.
Peinlich für mich: wie ist das zu verstehen, wie legts du eigene iVars an, Subclassing des oAppDlg und oAppDlg als Public anlegen?
Gruß
Markus
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Jan »

Ich kenne auch die Ausage das man PUBLICs meiden soll wie die Pest. Und nutze sie doch. Denn bevor ich anfange irgendwelche Verrenkungen umzusetzen gehe ich lieber den einfachen Weg mit den ungelibten PUBLICs. Und sehe bislang keine gravierenden Nachteile darin.

Ich habe Kundenprogramme gesehen, da war keine einzige LOCAL drin, da war wirklich alles PUBLIC. Wenn denn überhaupt deklariert. Und die liefen auch. Das Problem ist hier natürlich, das es zu Beginn unverständliche Fehlberechnungen etc. gab. Bis ich dahinter kam das die gleiche PUBLIC mehrfach zu unterschiedlichen Zwecken benutzt wurde. Das passiert halt leicht damit. Von daher baue ich sowas immer nach und nach auf LOCAL um. Aber wenn dann letztendlich ein oder zwei Dutzend PUBLICs übrig bleiben - wem schadet das jetzt genau? Mir nicht. Hab ich jedenfalls noch nicht feststellen können.

Ich selber benutze im Übrigen zwei Regeln im Umgang mit Variablen: Erstens werden die korrekt benannt. Also erster Buchstabe Inhalt der Variablen (n=Numerisch, c=Character, usw.). Erster Buchstabe klein, der zweite groß. Das hilft bei der Lesbarkeit. Und PUBLICs bekommen von mir noch ein "g" davor, für globale Variable. Klar wäre auch ein p gegangen, das ist irgendwie mal historisch so gekommen. Eine PUBLIC mit Characterinhalt heißt also z. B. gcName. Und zweitens benuze ich alle Warnschalter, um meinen Code möglichst sauber und fehlerfrei schon durch den Compiler laufen zu alssen. Und das zwingt mich dann dazu, PUBLICs mit MEMVAR-> anzugeben. Also z. B. MEMVAR->gcName. Das deklareirt die Variable dann eindeutig beim Gebrauch im Code.

Wie gesagt, diese Hype um das Verbot von PUBLICs kann ich nicht wirklich nachvollziehen. Ich habe selbst mit tausenden von denen in einem Progamm noch nie Probleme gehabt, die eindeutg auf deren Einsatz zurückzuführen wäre. Dennoch versuche ich die weitestgehend zu meiden, weil die eben den Code unübersichtlich machen. Und ja eventuell wirklich ein wenig langsamer sind als LOCALs...

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: Wohin mit den Publics

Beitrag von georg »

Hallo,


es scheint also eine Geschmacksfrage zu sein. Dann will ich mich auch einmal zu meinem Geschmack bekennen:

Nun denn, in meinen Programmen finden sich keine PRIVATEs oder PUBLICs. Das mag genauso ein Tick von mir sein wie die Tatsache, dass ich in anderen Sprachen den Befehl GOTO (Programmverzweigung) einfach nicht verwende. Es geht auch alles über Kontrollstrukturen (aber welchem Xbase++-Programmierer muss ich so etwas erklären?). (Ja, der Compiler macht aus meinem IF ein GOTO, aber das ist mir egal - mir geht es um die Lesbarkeit/Verständlichkeit meines Programmcodes und nicht um den Code, den der Compiler generiert.)

Seit Jahren verwende ich die Prüffunktionen des Compilers. Dazu gehört die Prüfung auf nicht deklarierte Variablen - das funktioniert nur mit LOCAL und STATIC und hat bei mir manchen Programmabsturz verhindert, weil ich mich mal wieder vertppit hatte. Das funktioniert mit dynamischen Variablen einfach nicht, weil die Deklaration ja theoretisch in einer anderen Programmquelle liegen kann.

Dazu kommt, dass eben Vertipper bei den Variablen-Namen dumme Nebeneffekte haben können, deren Ursache oft nicht so leicht zu lokalisieren ist. Dass man die Namen so vergeben sollte, dass sie sich nicht nur durch die Position eines Buchstabens unterscheiden, ist auch klar.

Ich bin der Auffassung, dass Variablen in ihrem Kontext definiert und genutzt werden sollen, und genau das tun die lexikalischen Variablen.

Nun kommt sicher die Frage, wie ich denn mit den Fällen umgehe, wo ich aus allen Modulen auf bestimmte Informationen zugreifen muss, sagen wir mal auf die XbpStatusBar(). In diesem Fall definiere ich eine Static in meinem Hauptmodul (das ist jenes, in dem sich Main() befindet), und eine Funktion, die mir diese Variable zurückliefert, etwa GetStatusBar().

Persönlich sehe ich Vorteile darin, weder PRIVATE noch PUBLIC zu verwenden (und auch GetList ist, wenn sie denn benötigt wird, in meinen Programmen eine Local Variable). Und ein sachkundiger Dritter, der sich mal mit meinem Programmen rumschlagen muss, wird nicht danach suchen müssen, wo pStatusBar deklariert/beschickt wird, sondern muß nur nach der Funktionsdeklaration von GetStatusBar() suchen.

Aber, wie getippt, das ist meine Meinung.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Herbert »

Tom hat geschrieben:Hiervon abgesehen sind PUBLICs ganz simpel programmglobale Variablen, und das ist in manchen Situationen unverzichtbar. Sie sind nicht von Haus aus besonders anfällig oder so, aber sie sind eben: PUBLICs. :wink:
Und auch "fehleranfällig" ist meiner Erfahrung nach höchstens die Verwendung.
Genau.
Wie bei allen variablen stellt sich die Frage nach dem Zweck des in der Variable gespeicherten Inhalts. Public heisst überall verfügbar und mit dem zuletzt gesetzten Wert sichtbar. Wann soll dessen Wert ändern und wann nicht? Ändert der Wert nie, so kann die Variable auch ausgelagert werden, z.B in eine Steuerungs-dbf oder in eine .ch Datei, um im Code mit include hervorgeholt zu werden.
Die eindeutige Bezeichnung der Variablen (nach Typ und Art), wie von Jan angetönt, sollte Pflicht sein (Stichwort ungarische Notation).
Und hilft, wie Georg richtig bemerkt, der Lesbarkeit des Codes.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von brandelh »

@ JAN,

Privates und Publics sind hauptsächlich dann tötlich, wenn man mit mehreren Entwicklern arbeitet, bzw. Code von verschiedenen Autoren kombiniert.
Die Wahrscheinlichkeit wächst einfach, dass ein Namenskonflikt Nebenwirkungen erzeugt.

ABER wenn man das wie du schreibst mit dem Namensraum sauber abdeckt, muss das kein Probelm sein.

Dass sie etwas langsamer sind spielt auch nur in Schleifen eine Rolle, wer FOR NEXT mit private x macht, statt local x wird Unterschiede messen können ...
da die Rechner heute so schnell geworden sind, ist Speed eh meist nicht mehr das Thema.
satmax hat geschrieben:
brandelh hat geschrieben:Ich nutze heute keine Publics mehr, wenn ich Variable für das gesamte GUI Programm benötige, dann lege ich iVars im Hauptfenster an.
Peinlich für mich: wie ist das zu verstehen, wie legts du eigene iVars an, Subclassing des oAppDlg und oAppDlg als Public anlegen?
Beispiel, mein Sachbearbeiter meldet sich am Programm an, die UserID gilt für das ganze Programm, ebenso kann er z.B. einen speziellen Drucker auswählen, auch für dieses Fenster ... andere nutzen den Standarddrucker. Dazu habe ich im XbpDialog() iVars angelegt, von denen ich aus dem Fensterheraus einfach zugreifen kann:

Mit dem XppFD (Formdesigner) habe ich ein Grundformular erstellt, und den CLASS Code erzeugt, Name __TestFenster (mit 2 _ vorne)
In der abgeleiteten PRG (das ist so bei CLASS CODE !) steht etwa sowas drinn (automatisch vom XppFD):

Code: Alles auswählen

CLASS _TestFenster FROM __TestFenster
   EXPORTED:
      METHOD init
      METHOD create
ENDCLASS
ich brauche nun einmal eine Funktion die mein Testfenster direkt öffnet ohne dass ich soviel schreiben muss und die beiden iVars:

Code: Alles auswählen

function TestFenster() // diese Funktion erzeugt einfach ein Fenster, man könnte hier auch noch Berechtigungen etc. abfragen !
   local oWin
   oWin := _TestFenster():New(RootWindow():drawingArea,RootWindow():drawingArea)
   oWin:Create()
return NIL
hier nun meine Klasse mit den neuen Variablen, natürlich kann man auch mehr anlegen, insbesondere Variablen, die nur im Fenster sichtbar sind PROTECTED ;-)
Da ich aber auf meine eigenen Variablen auch über CodeBlöcke und in der XppErrorsys zugreifen will, muss ich die Exported anlegen

Code: Alles auswählen

CLASS _TestFenster FROM __TestFenster
   EXPORTED:
      METHOD init
      METHOD create
      VAR cUserID   // Steffen sagte einmal iVars sollen keine Typkennzeichner vorne haben, ich finde das trotzdem praktisch.
      VAR cPrinter   // wenn NIL oder "", dann Standarddrucker verwenden.
ENDCLASS
METHOD _TestFenster:init( oParent, oOwner, aPos, aSize, aPP, lVisible )
   * Methode der Superklasse rufen
   ::__TestFenster:init( oParent, oOwner, aPos, aSize, aPP, lVisible )
   // Besser trennen oder gleich in einer Datei schreiben ???
   ::cUserID := ""
   ::cPrinter := ""
RETURN self
Im Fenster selbst kann man über ::cUserID zugreifen, von außen über das FensterObjekt, z.B. oTestDlg:cUserID
oder wenn es das aktuelle Fenster ist SetAppWindow():cUserID.

Wenn ich einen Drucker für das ganze Programm anlege, geht das genauso, aber ich verwende mein Hauptfenster dafür.
Und greife über RootWindow():cUserID zu (diese Funktion habe ich vom MDI Beispiel übernommen) ...

Wobei Alaska für Programmweite Infos das Applikation Objekt eingeführt hat, das geht im Prinzip genauso:

XppApplication() => Applikation Objekt => GetApplication()

Ich habe dieses neue Objekt allerdings noch nicht benötigt.
Gruß
Hubert
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Wohin mit den Publics

Beitrag von Werner_Bayern »

Ich benutze keine einzige Public. Wüsste auch nicht, wofür ich die noch brauche?
Es gibt nur in der Main ein Private-Array (Systemeinstellungen), das wars. Auch die müsste eigentlich nicht sein, weil man die ja je nach Bedarf sauber an jede Funktion übergeben kann.
In der Main definiert, ist die Private ja überall sichtbar. In Threads nicht, damit ist das sauber gekapselt. Will ich sie im Thread benutzen, übergebe ich sie einfach mit an den Thread - und ist somit dort eine local, ohne Seiteneffekte.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wohin mit den Publics

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben:Ich benutze keine einzige Public. Wüsste auch nicht, wofür ich die noch brauche?
für die Errorsys wenn man Threads benutzt.

ich kann es zwar immer noch nicht "beweisen" ( Demo ) aber eine PRIVATE, welche in der Errorsys genutzt wird, sollte man mit

Code: Alles auswählen

IsMemvar(mPrivat)
abfangen wenn man (GUI ?) Threads verwendet.
im Thread
ERROR LOG of USER ??? Ver.??? "D:\ALASKA\Cal\OLCAL.EXE" Date: 03.12.2014 06:17:37
...
Called from (B)MAGICHELP:DISPLAYTOOLTIP(345)
Called from MAGICHELP:DISPLAYTOOLTIP(345)
Called from MAGICHELP:SHOWTIP(261)
Called from MAGICHELP:EXECUTE(188)

normal
ERROR LOG of P1600NW Ver.v2.25 "D:\ALASKA\CAL\OLCAL.EXE" Date: 03.12.2014 06:40:27
...
Called from SLIDESHOW(612)
Called from MAIN(512)
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Wohin mit den Publics

Beitrag von Werner_Bayern »

Jimmy,

kannst mir das erklären?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Wohin mit den Publics

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben:kannst mir das erklären?
warum eine PRIVAT "nicht immer" in der 1st Errorsys "sichtbar" ist ... ?

Ich hab es zwar irgendwann mal festgestellt (rekursiver Fehler) und es mit IsMemvar() abgefangen,
aber ich hab es noch nicht geschafft ein Demo zu machen um es zu provozieren.

*** möglicher Erklärungsversuch ***

Ashton Tate hat sich damals bei dBase ][ an der Windows API orientiert. Die DBF Struktur z.b. ähnelt einer API Structur.

für eine (Speicher) Variabel muss nun ein Platz reserviert werden welche bis zum beenden des Programms blieb.
es gab damals nur PUBLIC und PRIVAT wobei diese einen kleinen Unterschied aufwiesen :
die "Sichtbarkeit" von einer PRIVATE war erst ab dem PRG ( damals alles einzelne PRGs ) wo es definiert wurde und "darunter" aber nicht "darüber".

Code: Alles auswählen

PROC START
PUBLIC a = 1
DO blabla()
? a
? b   // die kennt er unter dbase ][ / III+ nicht
RETURN

PROCEDURE blabla
PRIVAT b = 2
? a
? b
DO weiter()
RETURN

PROCEDURE weiter
? a
? b
RETURN
das ein Unterschied noch immer existiert merkt man auch an RELEASE ALL denn
Help File
PUBLIC Variablen werden bei RELEASE ALL nicht erfaßt.
deshalb nehme ich jetzt für Variablen, welche ich in der 1st Errorsys die vor MAIN geladen wird, verwenden will den Type PUBLIC wenn ich mit Threads arbeite.
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Wohin mit den Publics

Beitrag von Werner_Bayern »

AUGE_OHR hat geschrieben:deshalb nehme ich jetzt für Variablen, welche ich in der 1st Errorsys die vor MAIN geladen wird, verwenden will den Type PUBLIC wenn ich mit Threads arbeite.
Um was zu erreichen, was mit locals nicht geht?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Herbert »

Wir sprechen ja von Public und nicht von private, die man ohnehin nicht verwenden sollte.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Wohin mit den Publics

Beitrag von Manfred »

ok, jetzt haben wir wieder eine Behauptung, wie bei den Publics. Warum keine Privates benutzen?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von brandelh »

PRIVATES sind PUBLICS begrenzt auf die aktuelle und alle aufgerufenen Funktionen.
Sie sind weder schneller noch besser gegen Nebenwirkungen geschützt :!:

Technisch sind sie ohne Probleme einsetzbar und die Implementation ist fehlerfrei und lange erprobt.
Wenn man weiß was man tut und wo man aufpassen muss (Überscheidung von Variablennamen) kann man gut damit leben. Aktuelle Rechner sind eh schnell genug.

LOCALS sind nicht nur schneller, sondern auch sicherer, weil diese immer auf eine Routine begrenzt sind.
Gleiche Namen können somit nicht stören.

Was mir fehlt wären GLOBALS (also einmal definiert immer verfügbar), und Konstanten, die man einmal definiert (im MAIN) und überall lesen kann (und nur das).
Die "Konstanten" die man in jedem Quellcode oder per CH einbinden muss, sind dafür kein Ersatz !
Gruß
Hubert
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Koverhage »

Gleiche Namen können somit nicht stören.
Das möchte ich bezweifeln, je nachdem in welche Richtung man schaut.
Beispiel: Eine Public/Private cKundenname mit dem richtigen Inhalt
Dann eine Local Variable cKundenname definiert und man wundert sich warum dort der Name nicht drin steht.
Gruß
Klaus
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von brandelh »

Klaus,

Zitate darf man nicht aus dem Zusammenhang reißen [-X

Natürlich meinte ich in dem Absatz, wenn man nur LOCALs verwendet, muss man sich um die Namen keine Sorgen machen !
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Jan »

... und wenn man sich, wie hier schon öfters erwähnt, Namenskonventionen schafft, KÖNNEN eine PUBLIC und eine LOCAL niemals gleich heißen. Alles eine Frage der Planung und Disziplin.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von brandelh »

Jan hat geschrieben:... und wenn man sich, wie hier schon öfters erwähnt, Namenskonventionen schafft, KÖNNEN eine PUBLIC und eine LOCAL niemals gleich heißen.
Alles eine Frage der Planung und Disziplin.
Jan
stimmt :D solange man keinen fremden Quellcode einsetzt :wink:
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von Jan »

Hallo Hubert,

das ist sicher ein großes Problem. Ich habe keinerlei Hemmungen, solchen Code umzuschreiben. Aber das ist auch nicht immer ganz einfach. Ich arbeite z. B. gerade an einem alten Kunden-Projekt, das seine Wurzeln noch in DBASE 2 hat, und über Clipper dann nach Xbase++ gekommen ist. Da ist traditionell jede Variable PUBLIC, wenn die überhaupt deklariert wurde. Es gibt tausende davon! Ich habe schon mehrere Hundert korrigiert/umgeschrieben, und alles, was ich neu schreibe oder umschreibe, wird natürlich sofort korrekt benamt, soweit möglich. Aber die Korrekturen der Altlasten nehmen unglaublich viel Zeit in Anspruch. Ich habe dadurch auch schon teilweise schon Fehler eingebaut. Denn nicht alles läßt sich einfach auf LOCAL umschreiben. Manches muß (zumindest vorerst) noch PUBLIC bleiben. Anderes kann LOCAL werden, muß aber in jeder Funktion, in der das vorkommt, eingetragen werden. Manchmal erfordert das Umschreiben auf LOCALs auch, das der Code geändert wird. Parameterübergabe gibt es nämlich da noch nicht. Will ich das auf LOCAL umschrieben, muß ich aber Parameter benutzen. Was ja auch absolut OK ist. Aber es ist natürlich eine Wahnsinns-Arbeit. Und produziert auch mal einen neuen Fehler, wenn ich irgendwo nicht 100% aufgepasst habe.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Wohin mit den Publics

Beitrag von satmax »

Wie sagte schon Murphy: jeder mögliche Fehler wird passieren. :)

Oder als ganzes zitiert:
„Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen.“
Gruß
Markus
Antworten