Methoden-Parameter soll Referenz, aber kein nil sein können

[Meflin]

Das Feature, was du hier eigentlich willst, sind Nullable Types. Aber eigentlich egal, auch das kann Delphi nicht
(Andere Sprachen lösen das Problem, indem sie gleich auf das Fail-by-Design Konstrukt von Nullwerten verzichten... siehe z.B. Options in Scala).

In deinem Fall kann man nur sagen: In den Methodenkommentar/Doku schreiben, dass null nicht erlaubt ist, und fertig. Alles andere ist verschwendete Zeit

[Namenloser]

Zitat von himitsu:

Was meinst du denn mit statisch?

Sowas wie der Compiler auch macht, wenn er z.B. sagt "Warnung: Result ist möglicherweise undefiniert" oder "Warnung: Auf Variable X zugewiesener Wert wird nicht benutzt", nur eben komplexer und ausgeweitet.

https://de.wikipedia.org/wiki/Statische_Code-Analyse

[Mikkey]

Zitat von Namenloser:

Zitat von himitsu:

Was meinst du denn mit statisch?

Sowas wie der Compiler auch macht, wenn er z.B. sagt "Warnung: Result ist möglicherweise undefiniert" oder "Warnung: Auf Variable X zugewiesener Wert wird nicht benutzt", nur eben komplexer und ausgeweitet.

https://de.wikipedia.org/wiki/Statische_Code-Analyse

Einfacher gesagt: einen Fehler in der Art

Code:

Eine Konstante mit dem Wert 'abc' darf gemäß Einschränkung der Methode nicht als Parameter verwendet werden

[Furtbichler]

Nebenbei: Entgegen landläufiger Meinung sind null-Referenzen weder ansteckend noch gefährlich. Man muß halt nur wissen, wann sie erwünscht sind, und wann nicht.

Fail-Fast und Gehirnschmalz (immer zusammen verwenden) in nichthomöopatischer Dosis löst dieses Problem (und erstaunlich viele andere) ebenso zuverlässig wie nachhaltig.

Zitat von Meflin:

In den Methodenkommentar/Doku schreiben, dass null nicht erlaubt ist, und fertig. Alles andere ist verschwendete Zeit

Ja, und eben ein kleines Assert am Anfang, wie schon erwähnt und eigentlich auch logisch.

Mir scheint, hier wird der Wunsch nach einem mitdenkenden Compiler laut, der nicht nur syntaktische, sondern auch semantische Fehler in statu nascendi erkennt. Dann aber bitte gleich mit Codegenerator, dem man einfach das Problem durch verzweifelte Blicke und Gestiken vermittelt.

[Christian Seehase]

Moin Günther,

um mal auf das Beispiel Deines Eingangspostes zu kommen:
Wenn Du den Parameter als var oder out deklarierst und nicht als const lässt sich zumindest die Konstante nil nicht übergeben.

[Sherlock]

Zitat von jensw_2000:

Hoffentlich baut EMBT das irgendwann mit ein.
Wird echt mal wieder Zeit für ein paar echte Delphi Features, anstatt nur Halbherzigkeiten drum herum zu bauen.

Um Himmels Willen bloß nicht! Lass die doch erstmal in Ruhe Bugs fixen, FMX beschleunigen und sonstiges Gerümpel erledigen. Diese überflüssige Featuritis macht mich krank.

Früher mussten wir die Lochkarten von Hand ausstechen und den Stapel 5km zu Fuß, bergauf und im Schnee ins Rechenzentrum tragen, damit er dort eingelesen werden konnte. Wenn ein Bug drin war mussten wir zurück...zu fuß 5km durch den Schnee bergauf....seltsam, wenn ich daran zurückdenke. Aber worauf ich hinauswill: Man braucht das nicht! Und es wird maximal dann sinnvoll, wenn der Rest halbwegs funktioniert.


Sherlock

[himitsu]

Zitat von Mikkey:

Code:

Eine Konstante mit dem Wert 'abc' darf gemäß Einschränkung der Methode nicht als Parameter verwendet werden

Gut, wenn es dann eingebaut wurde und der Compiler das erfolgreich verhindert ... Wer hindert dann das laufende Programm daran diesen Wert gut versteckt in einer Variable zu übergeben?

[Mikkey]

Zitat von himitsu:

Wer hindert dann das laufende Programm daran diesen Wert gut versteckt in einer Variable zu übergeben?

Niemand (bzw. die Überprüfung, die der intelligente Compiler in die Methode einbaut).

Es werden ja auch Warnungen wegen nicht initialisierten lokalen Variablen nicht zuverlässig ausgegeben bzw. nicht ausgegeben.

Ich selbst muss sowas auch nicht unbedingt haben, ich wollte nur die Intention weitergeben. (OT Mir wären zutreffendere Compilermeldungen viel wichtiger.

[jfheins]

Kurze Antwort: Geht nicht.
Lange Antwort:

Zitat von Meflin:

Das Feature, was du hier eigentlich willst, sind Nullable Types.

Glaube ich nicht. Es klingt eher nach nicht-nilbaren Referenztypen (bzw. non-nullable reference types)

Da wird auch schön erklärt, dass das nachrüsten von denen nicht unter beibehaltung von Kompatibilität möglich ist. Der Speicher für ein neues Objekt muss ja erst alloziert werden. In diesem Moment wird der Speicher mit Nullen gefüllt. Wird der Thread genau danach unterbrochen, kann ein anderer Thread das Objekt beobachten. Referenztypen haben damit standardmäßig den Wert nil (weil eben ein 0x00000000 im Speicher steht) und Wertetypen ebenfalls 0 oder 0.0
Es ist eben kein Zufall, dass das Bitmuster 0x00000000 für alle Typen einen gültigen Wert darstellt.

Design by contract trifft eigentlich schon sehr genau das, was der TE will:

Delphi-Quellcode:

require
  aMyReference <> nil;

davor schreiben. Entweder kann der Compiler durch Codeanalyse feststellen, dass der Parameter niemals zu nil werden kann. Oder er wirft einen Fehler und zwingt den Programmierer eine entsprechende Prüfung einzubauen. (Wahrscheinlich im Fall = nil eine Exception werfen...) Und ja, die Prüfung geschieht bereits zur Compilezeit, soweit möglich. Genau so wie der Compiler ja auch schon ermittelt "Variable x wird ein Wert zugewiesen, aber niemals benutzt" kann er auch nil-Referenzen verfolgen und eine "Vertragsverletzung" feststellen.

Ich finde aber auch die Argumentation schlüssig, dass ein nicht-nilbarer Referenztypen (bzw. non-nullable reference type) nicht viel zur Sprache beiträgt. Gäbe es diesen Typen, müsste sich diese Anforderung ja nach oben hin ausbreiten. Die Variable, die ich hinen stecke, müsste ja genau so nicht-nilbar sein. (Ähnich wie in Java: Ich muss Exceptions entweder fangen oder deklarieren dass die Methode diese werfen kann)
D.h. ich habe den Null-check eben weiter oben in der Hirarchie, aber letztlich nicht gespart.

P.S.: Zusammenfassung aus dem Link oben:

Zitat:

So, long story short: non-nullable reference types is a great idea, but as a practical manner, the objections to implementing it now are enormous. Non-nullability is the sort of thing you want baked into a type system from day one, not something you want to retrofit in 12 years later. Keep that in mind the next time you design a new type system!

[Der schöne Günther]

Zitat:

Design by contract trifft eigentlich schon sehr genau das, was der TE will:

Ja, nachdem ich jetzt nochmal das kürzliche Thema Verträge für Delphi / Design by Contract gelesen habe, merke ich das auch