Suche "Programmier-Sprachen-Theoretiker"
-
Helium schrieb:
Andere Sprachen lösen das Problem damit, dss sie einfach null aus der Sprache verbannen. Stattdessen kann man dann mit optionalen Typen arbeiten, wenn man will (vor allem lösen sie das Problem und verstecken es nicht vor dem Programmierer).
Ja, so gehört es auch. Das ganze null-Zeug ist ein riesengroßer Mist, wenn man es sich nicht aussuchen kann. In praktisch allen Mainstream-Sprachen sind Zeiger nullable, ohne dass man was dagegen machen kann.
(Löst aber nicht das Problem mit der Speicherverwaltung, um das es ursprünglich ging)
-
Warum willst du das Konmzept in ne neue Programmiersprache packen(Die Entwicklung ist seehr aufwendig und teuer), wenn man sdie Idde in c++ verwirklichen kann(ist güstig machbar und dann ausprobierbar).
-
Dieses Konzept ist nur _eines_ von vielen. Dieses allein würde für mich nicht
eine neue ProgrammierSprache rechtfertigen. Es steht aber nicht allein.Ich versuche die Erzeugung von Null-Objekten zu automatisieren, um sie leichter zur Verfügung zu stelle.
Das vereinfacht die Bereitstelung und fördert den Gebrauch.In C wäre es möglich einen Mechanismus in der Art der Exceptions bereitzustellen.
Weil es jedoch nicht Teil der Sprache ist, findet es auch keine Verbreitung.Nach Rücksprache bin ich überzeugt worden, für "tote" Objekte eine eigene Klasse von
Zombie-Objekten zu erstellen, übere deren Funktion ich mir jedoch erst im Klaren werden
muss. Die Anwendung der Null-Objekte reduziert sich auf etwas, daß schön beschrieben
wird mit:"Something for Nothing", eine Art Null-Element.
Wie diese genauer zu definieren sind, muß ich mir ebenfalls genauer überlegen, weil
in die Mengen-Lehre "nicht richtig funktioniert" wenn sie Null-Elemente enthält. Ich
muß schauen, daß ein Null-Element zu interpretieren ist als eine Art Indikator einer
"Leeren Menge". Ob das mit der Interpretation zu lösen ist, oder ob das in der
Implementierung zu berücksichtigen ist, kann ich noch nicht sagen.Die Trennung zwischen "hat's nie gegeben" und "gabs mal aber ist jetzt tod" ist semantisch sinnvoll.
Ich muss das im Kopf erstmal durchspielen.
Das Null-Objekt-Konzept allein ist nicht ausreichend Grund für mich um eine neue
ProgrammierSprache zu begründen. Eher ein Detail. Ich fand es nur schön als Beispiel,
um ein einzelnes losgelöstes Detail vorzustellen.
Seit ein namenloser Admin seine absolute Authorität als neutrale Aufsicht verspielt hat,
fühlen sich ein paar Nachläufer ermutigt diesen Thread mit kontra-produktiven Post zu füllen.Allein daß dieser Thread aus der Projekte-Kategorie entfernt wurde ist :xmas2: :xmas2: :xmas2:
Daß dieser Thread nicht mehr an den Posts eindeuting als Projekt zu erkennen ist, ist ebenso
Leistung der tüchtigen Admins. Ihn dann aber aus der Kategorie Projekte zu entfernen ist ... drollig!
Oder schreibt man das mit 't'? Mir ergibt sich eine ganze Kaskade von weiteren Fragen.Der Gebrauch der Zombie-Threads ist insbesondere für Multi-Threaded-Applications sinnvoll, weil
da die linke Hand nit so genau weiß was die rechte macht.
Stell dir vor du bist ein Thread und ich bin ein Thread - und irgendwo steht ein Objekt.
Ich schlag es "tod"! Warum muß ich dir erklären daß es tod ist, wenn es dir dass noch trotz
seiner Totheit doch selber erzählen könnte, sondern stattdessen, weil du dieses nicht extra mitgeteilt
bekommst und versuchst das Objekt zu benutzen wirst dadurch sooo iritiert daß du schliesslich abstürzt
und mich und den Rest der Applikation mit! Wo bleibt denn da die Logik? Jemand sagte mal:"Wenn die Häuser dieser Welt gebaut wären wie Computer-Programme,
dann würde ein einzelner Specht die Welt in Trümmern legen!"Aber da wird man gleich angesprochen im Sinne von:
"Dieses Haus würde nicht sofort zusammenklappen! Dies ist ein klarer Fehler!" *zustimmendes*gemurme*
Zum debuggen wär es wohl sinnvoll den Zombie-Objekten ein anderes Verhalten zu geben, um zu gucken wo
wirkliche Fehler sind. Ich favorisiere nicht fehlerhafte Programmierung sondern fehlertolerate Systeme.
Wenn ich zum Beispiel ein Array mit 100.000 Objekten habe die zufällig früher oder später "sterben",
dann will ich gerne 1-2% tote Objekte tolerieren, und erst beim nächsten Sanity-Circle diese zu entfernen
in dem das Array neu aufgebaut wird. So kann der Betrieb weitergehen, während das neue Array erstellt
wird und in den neuen Objekt-Zustand eingebunden, während alte Zugriffe mit dem alten Array fehlerfrei
weiterarbeiten können und neue Request das neue Array benutzen. So spart man Putzarbeit und erhöht den
Durchsatz und nebenbei die Stabilität.Die Frage nach dem Null-Objekt möchte ich gleichstellen mit den Fragen nach den Sinn von
-einer Null für die Addition
-einer Eins für die Multiplikation
-der Leeren Menge für die Mengenlehre
-dem Null-Device für File-Operationen
-etc.Allesammt könnte man sagen: Die machen doch nichts! Also wozu?
-
Wenn Du schon mit solchen Vergleichen kommst: In der Mathematik ist eine Division durch 0 undefiniert. Da führt man auch nicht einfach irgendeine Zahl ein, damit der Taschenrechner kein NaN anzeigt und man lustig weiter rechnen kann. Und Du willst doch nicht ernsthaft behaupten, dass man die 0 und die 1 weglassen kann, bloß weil sie zufälligerweise die neutralen Elemente der Addition bzw. Multiplikation sind? Die Frage nach deren Sinn ist leicht beantwortet. Entsprechendes gilt für die leere Menge.
-
lies doch bitte noch mal meinen post richtig durch.
du hast mich falsch verstanden wenn du glaubst ich wollte ernsthaft den Sinn der neutrale Element diverser Verknüpfugen in Frage stellen.
Im gegenteil! Ich wollte diese als Analogie zu dem von mir propagierten Null-Element nehmen, an dem sich einige Herren Anstoß nehmen.
-
Schon klar, was Du damit beabsichtigen wolltest. Die Analogie hinkt aber gewaltig.
-
schöne Analogie!
Beim Wurzelziehen schrieb man für negative Zahlen immer die leere Menge als LösungsMenge,
weil lange lange Zeit die Wurzel aus negativen Zahlen nicht definiert war.Aber dann führte man die Imaginäre Einheit i ein wobei i definiert ist als i²=-1
Fortan gelten Wurzeln aus negativen Zahlen als möglich nur liegt der WerteBereich
der WurzelFunktion außerhalb der Menge der Reellen Zahlen.Man hat den defnierten Bereich also erweitert und kann seitdem damit tolle Sachen machen.
Bei der Divison duch Null scheiterete eine Einführung einer "unendlichen Einheit" ∞
weil man die Annahme vertritt, daß ∞+∞=∞ ergeben müßte.
Das führt schnell zu Widersprüchen.Ich denke wenn man diese Annahme weglässt und eine bessere Vorstellung von der Unendlichkeit entwickelt,
(die alten Griechen hielten sogar alles größer 1000 für unendlich), dann läßt sich auch mit ∞
rechnen.Kurz: Nur weil man etwas definiert führt ess nicht zu einer dessen Widerspruchsfreiheit und damit zu einer
unproblematischen Existenz. Daß die Null-Streams den Character eines Neutralen Elements haben sollen muß ich
wohl nochmals unterstreichen. Und der Vergleich mit der undefinierten Operation 0/x kann ich gut akzeptieren.
Man kann ebend mit Null fast alles machen aber ebend nicht alles weil es ebend die Null ist. Ich finde dies
beschreibt sehr gut die Rolle bzw. Aufgabe, die ich den Null-Objekten zu geben beabsichtigte.
-
@MisterX
Ich möchte eine neue ProgrammierSprache entwickeln.
Die Null-Objekte selbst sind nicht der Grund dafür!Das Konzept der Null-Objekte halt ich für wichtig
genug, um es vorherein gleich mitzuimplementieren.
-
Schnapp dir ne dynamische Sprache, wie z.B. Smalltalk, bau dir ein Objekt, dass auf jede Nachricht damit reagiert sich selbst zurückzugeben und du hast dein Verhalten.
Dann kannst du dir angucken wie toll das doch ist, ohne eine neue Sprache erfinden zu müssen.... ach so, hat Objective-C nicht schon ein message eating nil?
-
Helium schrieb:
... ach so, hat Objective-C nicht schon ein message eating nil?
Ja hat's. Alle Nachrichten die an nil gesendet werden lösen sich quasi in nichts auf bzw. geben 0, NULL, nil oder NO zurück.
-
Deine Mathe-Analogie klappt deswegen nicht, da es in der Mathematik keine Seiteneffekte gibt. Vielleicht hab ich (& die anderen) dein Konzept nur falsch verstanden. Erklaer mal bitte, was in folgender Situation passieren soll (das Beispiel stammt von rapso):
es gibt 2 Threads, und die beiden greifen auf das gleiche Datenbankobjekt zu. Thread 1 loescht nun die Datenbank, sie wird also durch ein Null-Objekt ersetzt. Was passiert jetzt, wenn Thread 2 etwas in die Datenbank schreiben will?
Passiert gar nichts? Wird eine Exception geworfen? Oder wird ein Fehler zurueckgegeben?Ich seh in allen 3 Faellen nichts, was "immer sinnvoll" ist, und deswegen trifft deine Idee hier auf so viel Widerstand.
In Aussnahmefaellen mag so ein Verhalten, wie du es vorschlaegst, Sinn ergeben, aber selbst dann muss es in der Hand es Programmierers liegen zu entscheiden, was bei Verwendung des Null-Objekts passiert (weil es wie gesagt je nach Situation verschiedene "beste Loesungen" geben kann). Und genau dafuer gibts wie bereits erwaehnt ja das Null-Object-Pattern: http://www.cs.oberlin.edu/~jwalker/nullObjPattern/
Du wirst hier im Forum genug "Sprachtheoretiker" finden, und dass sich die meisten so gegen die Idee des universalen Nullobjects wehren, sollte dir zu denken geben. Wenn du nicht bereit bist, deine Ideen oeffentlich hier im Forum zu diskutieren (wozu ich dir aber raten wuerde, weil du dann ein viel breiteres Publikum ansprechen kannst), dann musst du wohl mit einer anderen tollen Idee locken, als mit etwas, das universell nicht funktioniert und fuer das es ansonsten bereits ein Pattern gibt.
-
Blue-Tiger schrieb:
Deine Mathe-Analogie klappt deswegen nicht, da es in der Mathematik keine Seiteneffekte gibt.
Sag das den Informatikern, die seit 60 Jahren ihre Wissenschaft auf der Mathematik aufbauen
es gibt 2 Threads, und die beiden greifen auf das gleiche Datenbankobjekt zu. Thread 1 loescht nun die Datenbank, sie wird also durch ein Null-Objekt ersetzt. Was passiert jetzt, wenn Thread 2 etwas in die Datenbank schreiben will?
Passiert gar nichts? Wird eine Exception geworfen? Oder wird ein Fehler zurueckgegeben?Das muss man sich für jeden Datentyp überlegen. Unter den Beispielen war ja z.B. das Null-Device, was jeden Schreibzugriff wirkungslos verpuffen läßt und bei Lesezugriffen stets EOF liefert. Bei Prozeduren wie etwas in die DB schreiben ist ein Null-Effekt sogar normalerweise ein sinnvolles Defaultverhalten, schwieriger wird es bei Funktionen.
Ich seh in allen 3 Faellen nichts, was "immer sinnvoll" ist, und deswegen trifft deine Idee hier auf so viel Widerstand.
Genau, ich denke, es liegt auf der Hand, dass das jeweils für jeden Typ speziell festgelegt werden muss.
-
Bashar schrieb:
es gibt 2 Threads, und die beiden greifen auf das gleiche Datenbankobjekt zu. Thread 1 loescht nun die Datenbank, sie wird also durch ein Null-Objekt ersetzt. Was passiert jetzt, wenn Thread 2 etwas in die Datenbank schreiben will?
Passiert gar nichts? Wird eine Exception geworfen? Oder wird ein Fehler zurueckgegeben?Das muss man sich für jeden Datentyp überlegen. Unter den Beispielen war ja z.B. das Null-Device, was jeden Schreibzugriff wirkungslos verpuffen läßt und bei Lesezugriffen stets EOF liefert. Bei Prozeduren wie etwas in die DB schreiben ist ein Null-Effekt sogar normalerweise ein sinnvolles Defaultverhalten
Erklaer das mal dem Kunden, dessen Geld nicht auf dem Konto verbucht wird.
-
Es wird schon einen Grund haben, dass die DB nicht existiert. Würde man explizit das NullObject-Pattern anwenden, würde auch kein Geld gebucht.
-
gorgoyle schrieb:
schöne Analogie!
Beim Wurzelziehen schrieb man für negative Zahlen immer die leere Menge als LösungsMenge,
weil lange lange Zeit die Wurzel aus negativen Zahlen nicht definiert war.Aber dann führte man die Imaginäre Einheit i ein wobei i definiert ist als i²=-1
Fortan gelten Wurzeln aus negativen Zahlen als möglich nur liegt der WerteBereich
der WurzelFunktion außerhalb der Menge der Reellen Zahlen.Man hat den defnierten Bereich also erweitert und kann seitdem damit tolle Sachen machen.
Und mit jeder Erweiterung eines Zahlenkörpers ist auch ein Mehrwert verbunden. Wo bitte also ist der Mehrwert (gegenüber vorhandenen Mechanismen) in der Einführung des von Dir vorgestellten Sprachfeatures, ausser dass es u.U. fehlerhafte Programme am crashen hindert? Das verstehe ich nicht ganz.
-
Bashar schrieb:
Es wird schon einen Grund haben, dass die DB nicht existiert. Würde man explizit das NullObject-Pattern anwenden, würde auch kein Geld gebucht.
aber dann koennte mitgeloggt werden, oder eine Exception geworfen, oder sonstwas. Dass Null-Pattern bietet mir ja die Moeglichkeit, da flexibel zu sein. Und der "Grund" koennte auch eine (unabsichtliche) Fehlbedienung des Benutzer oder ein Programmfehler sein.
-
Ja, wenn es nicht passt, dann darf man halt kein Defaultverhalten spezifizieren. Ich habe auch nicht das Gefühl, als wollte der OP Mengen von DBs über mehrere Threads verwalten, da geht es sicher um andere Objekte, bei denen sowas sinnvoll wäre.
-
Aber eine Exception zu werfen, wenn es ein NullObjekt ist, würde doch wieder eine Abfrage erfordern, die testet ob es ein Nullobjekt IST. Und eben das wollte der Autor des Threades hier je verhindern, oder irre ich da?
-
Blue-Tiger schrieb:
es gibt 2 Threads, und die beiden greifen auf das gleiche Datenbankobjekt zu. Thread 1 loescht nun die Datenbank, sie wird also durch ein Null-Objekt ersetzt. Was passiert jetzt, wenn Thread 2 etwas in die Datenbank schreiben will?
Passiert gar nichts? Wird eine Exception geworfen? Oder wird ein Fehler zurueckgegeben?Ich denke eine Datenbank ist i.a.R. nichts, die einfach so dezentral zerstört werden sollte und wenn doch,
dann werden alle weiteren Zugriff auf das Null-DatenBank-Objekt umgeleitet, und die ist sehr geduldig.Ich denke hier wäre ein Zombie-Objekt geeigneter, um auf den postmorten Mißbrauch aufmerksam zu machen.
Wie diese zu verallgemeinern wäre denke ich derzeit noch nach.Wenn der schreibende Thread zum Schluß prüft, ob sein DB-Objekt ein Null-Objekt, weiß er ob seine Daten
nicht wirklich erfolgreich übertrage konnte. Wenn eine andere zentrale Stelle nun entschieden haben sollte,
diese DB zu zerstören, wäre das vom Ablauf her kein Problem. Wenn eine zu zerstörende DB jedoch seine
Aufgabe noch erfüllen soll, wäre ein Zombie-DB geeigneter. Ich denke es lassen sich Fälle finden wo
Null-Objektee nicht geeignet sind eine Problematik zu zu lösen. Ich halte Null-Objekte für kein
AllheilMittel aber für sehr praktisch.
-
makkurona schrieb:
Aber eine Exception zu werfen, wenn es ein NullObjekt ist, würde doch wieder eine Abfrage erfordern, die testet ob es ein Nullobjekt IST. Und eben das wollte der Autor des Threades hier je verhindern, oder irre ich da?
Ich will nicht verhindern das eine Exception geworfen werden sondern es nur nicht notwendig machen dass eine Exception geworfen wird.
Ich möchte die Möglichkeit haben, etwas mit dem "Character" von Null zurückzugeben, das aber nicht zwangsläufig eine SonderBehandlung
erfordert. Sozusagen ein Null mit dem man weiterarbeiten kann auch wenn es nichts bewirkt. Wenn es wichtig ist zu wissen, ob es ein
Objekt ein Null-Objekt ist oder nicht, möchte ich die Methode bool isNull(); bereitstellen.Wie schon zuvor zitiert ein Null-Object ist "Something for Nothing" mit dem man ohe Ausnahme arbeiten kann.
Ein Unterschied zwischen Null und Null-Objekt ist jedoch daß ein Null-Objekt einen Typ besitzt und Null dagegen nicht.
So könnte man ein Null-Objekt auch als typisierte Null auffassen. Wenn bestimmte Zugriffe eine Exception auslösen sollen
kann man diese implementieren.