In der Tiefe: Validierungskonzept

[bmx]

Und welche Farbe hat Funk?

Das kommt auf die Wellenlänge drauf an ...

Gruß,
Bernd

[SnowMaKeR]

Eigentlich wollt ich es ja nicht verraten.
Ich hab hier schon ein Zubehörteil dafür.
Das Funk-Speed-Spray.

Es kann keinen Kaffee kochen

Hmmm, dann muss ich über den Kauf ernsthaft nachdenken.

[bmx]

Und ich biete hier noch passende Siemens-Lufthaken an, im Dutzend dann etwas billiger ...

Gruß,
Bernd

[saft6luck]

Und ich biete hier noch passende Siemens-Lufthaken an, im Dutzend dann etwas billiger ...

Sind das die Originalen oder eher günstige Importe aus China?

[Uwe!]

Gaaanz kalt, an dieser Stelle.

Daraus schließe ich: an anderer Stelle schon deutlich wärmer...

[salixer]

Und ich biete hier noch passende Siemens-Lufthaken an, im Dutzend dann etwas billiger ...

Wer entsorgt meinen Eimer Spannungsabfall?

[enertegus]

Hier mal wieder etwas zum Thema Valdierungskonzept für Fortgeschrittene. Da ergibt sich eine Erweiterung mit den Makro-Funktionen.

Theoretisch können wir das auch noch ändern, und grundsätzlich den erwähnten globalen Kontext lokalisieren - das wäre dann im Text, dass :return nicht gleichzeitig auch die Validierung festlegt, wie von mir so gedacht. Ich finde es aber so weitaus flexibler - vielleicht zu Kosten der Einfachheit (?). Ich stelle das mal vorsichtig zur Diskussion.

[saft6luck]

Mir ist unklar was das ganze mit dem Validierungschema zu tun hat.

So wie ich das verstehe wird eine Textersetzung durchgeführt:
- alles im Return ersetzt den 'Funktionsaufruf' im Code
- alles vor dem Return wird in die Hauptebene gesetzt

Wieso muss ich mir da Gedanken über ein vererbtes Validierungschema machen?

Wie würde denn eine Variante mit lokalen Variablen aussehen?

[enertegus]

[QUOTE=saft6luck;137222]
So wie ich das verstehe wird eine Textersetzung durchgeführt:
- alles im Return ersetzt den 'Funktionsaufruf' im Code
- alles vor dem Return wird in die Hauptebene gesetzt
[QUOTE]
Das ist so absolut richitg. Allerdings kann denkt man da leicht in ein Fahrwasser kommen, dass man ein paar Seiteneffekte vergisst.

Wie würde denn eine Variante mit lokalen Variablen aussehen?

Lokale Variablen sind quasi "verdeckte" globale Variablen mit einer speziellen Namensgebung. Diese wird vom Eibparser selbst generiert und zwar so, dass man diese nicht selbst definieren kann.
Ansonsten verhalten diese sich exakt gleich.

[saft6luck]

Ok, so hatte ich mir das vorgestellt. Dann könnte man ja dem Makro einen Parameter für die lokalen Variablen mitgeben, der deren Namen ergänzt -> kann man leicht selber machen.

Finde ich zwar umständlich und ein Kommando im Makro würde mir besser gefallen, à la ':local ...' und ':global', aber wenn nur entweder oder geht würde ich für global plädieren mit einer Anleitung für lokale Variablen im Text.

[SnowMaKeR]

Wenn die Verarbeitung eines „Programmdurchlaufs“ abgeschlossen sind

entweder Verarbeitungen oder ist

[enertegus]

Ok, so hatte ich mir das vorgestellt. Dann könnte man ja dem Makro einen Parameter für die lokalen Variablen mitgeben, der deren Namen ergänzt -> kann man leicht selber machen

So war das ja mal gedacht, doch der Anwenderkreis hier wollte ja eben lokale Definitionen.

Finde ich zwar umständlich und ein Kommando im Makro würde mir besser gefallen, à la ':local ...' und ':global', aber wenn nur entweder oder geht würde ich für global plädieren mit einer Anleitung für lokale Variablen im Text.

Das versteh ich nicht so ganz:
Lokale Variablen werden gesondert definiert, alle anderen sind global, oder was meinst Du da?

[saft6luck]

Lokale Variablen werden gesondert definiert, alle anderen sind global, oder was meinst Du da?

Ja, etwa so:

[highlight=epc]
:begin Akt(Aktor,Now)
:global
InitGA(Aktor)
Urlaub=AUS
:local
Variable=0
:return {
Variable=Variable+1;
if Now and !Urlaub then write(Aktor,Variable) endif
}
:end
[/highlight]

:global ist generell optional, ohne sind variablen auch global
:lokal ist optional. Variablen, die unter :local deklariert werden, werden vom Compiler wie von dir vorgeschlagen bei jeder Ersetzung eibPC-intern mit einer einmaligen Kennung ergänzt und sind somit programmtechnisch lokal.

Ob beide Schlüsselwörter nur einmal im Makro stehen dürfen ist dann von den Möglichkeiten des Parsers abhängig (vermeidet evtl. aber auch Fehler).

Übrigens: Warum brauch denn :return einen Block, während unter :begin keiner notwendig ist?

[saft6luck]

Hallo Michael,

kannst du mir noch schnell sagen, warum folgendes geht:
[highlight=epc]
// Sonnenuntergang
Rollo_Sonnenuntergang_verzoegerung = 20u08

Rollo_Sonnenuntergang_h = sunsethour()
Rollo_Sonnenuntergang_m = sunsetminute() + Rollo_Sonnenuntergang_verzoegerung; /* -> Minuten: 20 <= m <= 79 */

if change( Rollo_Sonnenuntergang_m ) then {
if ( Rollo_Sonnenuntergang_m > 59u08 ) then {
Rollo_Sonnenuntergang_m = Rollo_Sonnenuntergang_m - 60u08;
Rollo_Sonnenuntergang_h = Rollo_Sonnenuntergang_h + 1u08;
} endif
} endif
[/highlight]
folgendes aber nicht(?):
[highlight=epc]
// Sonnenaufgang
Rollo_Sonnenaufgang_frueher = 15u08

Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m = sunriseminute(); /* -> Minuten: 0 <= m <= 59 */

if change( Rollo_Sonnenaufgang_m ) then {
if ( Rollo_Sonnenaufgang_m < Rollo_Sonnenaufgang_frueher ) then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_m + 60u08;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_h - 1u08;
} endif;
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_m - Rollo_Sonnenaufgang_frueher
} endif
[/highlight]

Ich dachte das sollte gefixt worden sein?!

[enertegus]

Hallo Michael,
kannst du mir noch schnell sagen, warum folgendes geht:

Das zweite generiert u.U. (z.b Minuten auf 47 und Offset 50) eine Art Endlosschleife, da nach jeder Änderung "if change" immer wieder gültig ist.

Ich dachte das sollte gefixt worden sein?!

Was meinst Du sei hier nicht in Ordung? Auf die Schnelle (es ist ja schon spät [hoffentlich sieht das der Makki nicht, 23:00 und spät, tsss]) seh ich da nix Ungewöhnliches.