neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
Moderator: Moderatoren
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
hi,
ich habe zwar das PDF schon mehrfach gelesen aber es immer noch nicht begriffen.
könnte jemand es mal zusammenfassen "for Dummys"
ich habe zwar das PDF schon mehrfach gelesen aber es immer noch nicht begriffen.
könnte jemand es mal zusammenfassen "for Dummys"
gruss by OHR
Jimmy
Jimmy
- Martin Altmann
- Foren-Administrator
- Beiträge: 16516
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
Hallo Jimmy,
könnte ich! Da es aber noch nicht "final" ist, werde ich es jetzt noch nicht tun!!
Viele Grüße,
Martin
könnte ich! Da es aber noch nicht "final" ist, werde ich es jetzt noch nicht tun!!
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
hi,
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.
ok verstanden, dann stelle ich die Frage eben anders :Martin Altmann hat geschrieben: Da es aber noch nicht "final" ist, werde ich es jetzt noch nicht tun!!
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.
gruss by OHR
Jimmy
Jimmy
- Martin Altmann
- Foren-Administrator
- Beiträge: 16516
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
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.
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.
Gruß
Hubert
Hubert
- Martin Altmann
- Foren-Administrator
- Beiträge: 16516
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
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 ?
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 ?
Gruß
Hubert
Hubert
- Martin Altmann
- Foren-Administrator
- Beiträge: 16516
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
Hallo Hubert,
mir auch, aber naja.
Nope ist das Gegenteil von Yup.
Yup = Yes.
Nope = No.
Also nö.
Viele Grüße,
Martin
mir auch, aber naja.
Nope ist das Gegenteil von Yup.
Yup = Yes.
Nope = No.
Also nö.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
Nachdem ich das PDF nun gelesen habe, wollte ich dir wegen REGEL 2 (FINAL CLASS - it is final) eigentlich widersprechen,Martin Altmann hat geschrieben: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
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
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
hi
"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.
ich hatte nur das 1MB PDF gelesen und beim Download hat er vermutlich den Datei Namen alsMartin Altmann hat geschrieben: 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!
"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.
gruss by OHR
Jimmy
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15696
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: neue OOP Futures: FINAL | INTRODUCE | OVERRIDE
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 !
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 !
Gruß
Hubert
Hubert