neue OOP Futures: FINAL | INTRODUCE | OVERRIDE

[AUGE_OHR]

hi,

ich habe zwar das PDF schon mehrfach gelesen aber es immer noch nicht begriffen.
könnte jemand es mal zusammenfassen "for Dummys"

[Martin Altmann]

Hallo Jimmy,
könnte ich! Da es aber noch nicht "final" ist, werde ich es jetzt noch nicht tun!!

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Da es aber noch nicht "final" ist, werde ich es jetzt noch nicht tun!!

ok verstanden, dann stelle ich die Frage eben anders :

Wenn Xbase++ neue Futures bekommen "würde" wie FINAL | INTRODUCE | OVERRIDE wie "würde"
es sich auf bestehende OOP Class auswirken. Müsste ich damit rechnen das, wie bei "visual Style",
sich meine Application "verändert" ?

gut wäre natürlich ein Beispiel wo ich mit dem "aktuellen" OOP System "an die Grenzen" käme und
eine Erweiterrung gebrauchen könnte ... und genau das ist der Punkt der mir nicht einleuchtet.

Ausser "Override" sehe ich den Sinn der neuen Futures nicht ( es sein den man programmiert so
wie in den Beispielen )

... weit hergeholter Vergleich ...

Es scheint mir so als wenn man alles auf "LOCAL" Memvars umgestellt hat und dann das Futures
"GLOBAL" käme ... wozu "mehr" wenn ich "weniger" haben möchte ?

Eine vorgegebene Methode zu "override"n macht ja Sinn, aber wenn ich eine Class schreibe so
"kapsel" ich die doch damit ich verschiedene Instanzen benutzen kann. Ob ich den Code dann
"so" wie in den Beispielen schreiben würde ... macht "das" Sinn ?
Müssten neu Futures nicht "striktere" Grenzen ermöglichen statt die "aufzuweichen" ?

ok ich muss die neuen Futures ja nicht nutzen und bislang hatte ich gehofft das ganze bloss
nicht zu verstehen, aber im Help File hat mich das (Alaska typische) Beispiel mehr verwirrt als
geholfen.

hm ... ich stelle gerade fest das mein PDF "nur" 1MB gross ist und die "lates" 3.5MB ... ok
nochmal das "grosse" PDF lesen vielleicht finde ich ja noch was.

[Martin Altmann]

Hallo Jimmy,
OK - ich war davon ausgegangen, dass Du das PDF gelesen hattest. Da wird das eigentlich recht klar...
Und Alaska hatte tatsächlich was geändert an dem Default-Verhalten! Das haben sie (zum Glück) im letzten drop wieder zurückgedreht!

Viele Grüße,
Martin

[brandelh]

So wie ich das verstehe, hat der Entwickler einer Bibliothek nun die Möglichkeit das Ableiten und Ändern von Methoden einzuschränken bzw. zu steuern.

Angenommen du stellst für den Zugriff auf ein Teil (Hard- / Software) von dir eine Bibliothek
zur Verfügung und möchtest nicht, dass der Anwender mehr damit machen kann als du vorgesehen hast, dann setzt man FINAL.

Nach den Protesten müsste das bisherige Standardverhalten aber beibehalten worden sein.

[Martin Altmann]

Hallo Hubert,
nope
Naja, fast! Wenn FINAL, dann muß in der vererbten Klasse explizit OVERRIDE gesetzt werden, dann wird das FINAL überschrieben...
Es kann dann jedenfalls nicht "versehentlich" passieren

Viele Grüße,
Martin

[brandelh]

Hi,

das erscheint mir jetzt aber inkonsequent

PS: Ich gebe zu ich habe das neue PDF auch noch nicht gelesen

PSS: Was heißt jetzt NOPE nochmal ?

[Martin Altmann]

Hallo Hubert,
mir auch, aber naja.
Nope ist das Gegenteil von Yup.
Yup = Yes.
Nope = No.
Also nö.

Viele Grüße,
Martin

[brandelh]

Hallo Hubert,
nope
Naja, fast! Wenn FINAL, dann muß in der vererbten Klasse explizit OVERRIDE gesetzt werden, dann wird das FINAL überschrieben...
Viele Grüße,
Martin

Nachdem ich das PDF nun gelesen habe, wollte ich dir wegen REGEL 2 (FINAL CLASS - it is final) eigentlich widersprechen,
aber dann sah ich unten auf der letzten Seite weiß auf blau unter REGEL 6 - FINAL methods können immer noch mit OVERRIDE überschrieben werden ...

Da man aber METHODEN selbst nicht in der gleichen Klasse überschreiben kann, muss man doch die CLASS vererben können, oder ?

Nun ja, bei Gelegenheit werde ich dies einmal ausprobieren

Was mich viel mehr nervt ist, dass SUPER nun auf 1.90.347 verschoben wurde ... das ist Regel #4

Von mir frech übersetzt, "und wartest du auf etwas ganz besonders, wird es aufs nächste mal verschoben" ich hoffe nur, dass Regel 4 nicht zur Regel wird

[AUGE_OHR]

hi

OK - ich war davon ausgegangen, dass Du das PDF gelesen hattest. Da wird das eigentlich recht klar...
Und Alaska hatte tatsächlich was geändert an dem Default-Verhalten! Das haben sie (zum Glück) im letzten drop wieder zurückgedreht!

ich hatte nur das 1MB PDF gelesen und beim Download hat er vermutlich den Datei Namen als
"vorhanden" angesehen sodas ich den dann wohl abgebrochen habe. Nun hab ich die 3MB Version
gelesen und bin zwar "etwas" erleichtert aber ich "wittere" da schon wieder "Ungemach".

Es mag sein das ich nicht viel mit PROTECT: arbeite. Ich habe lieber alles "offen" und
dokumentiere lieber alles und sag dann "Intern" dazu sodas man es besser nicht "so" benutzen
"möge" ... aber nicht "zwinge" oder "verbiete" ... so ist auch mein Programmier Stil.

Wie schon gesagt ich komme nicht dahinter "warum" ich nun sowas wie FINAL oder OVERRIDE
haben ... oder braucht Alaska "das für sich" ? Je mehr Möglichkeiten ich zum "einschränken" habe
desto mehr Möglichkeiten hat doch dann auch Alaska ? Könnte man nicht auch XbParts dahin
drehen das ich zum "nutzen" z.b. einen :Licence Key brauche ...

wie auch bei Politikern bin ich immer ein wenig misstrauisch wenn einem "Benefits" angepriesen
werden ... nicht alles "von oben" ist auch von Vorteil für die "da unten" den es gibt immer 2 Seiten
und dafür suche ich noch Beispiele zum besprechen wo/wie/warum wir davon was haben.

[brandelh]

Hallo Jimmy,

du machst dir zu viele unnötige Sorgen

Solange du für dich arbeitest, brauchst du weder auf PROTECT noch auf sonst was zurückgreifen.
Die FINAL etc. sind - so sehe ich das - nur für Entwickler von Frameworks, z.B. auch um in einer
Firma eine Firmenregel durchzusetzten. Dass in diesem Zusammenhang FINAL doch überschrieben werden kann passt nicht zusammen, immerhin wird das versehentliche Überschreiben verhindert.
(Allerdings spart man sich bei sauberem Design viel Ärger und Fehlersuche ... )

FALLS - Alaska jemals auf die Idee käme von uns Lizenzgebühren je entwickelter Anwendung zu verlangen, könnten sie das technisch sehr leicht machen, aber wirtschaftlich wäre das wohl der Todesstoß. Ich glaube nicht, dass auch nur ein Kunde das akzeptieren würde !