Suche "Programmier-Sprachen-Theoretiker"
-
@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.
-
gorgoyle schrieb:
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.
Schonmal den Begriff der referenziernden Garbage Collection gehört?
-
oks schrieb:
Schonmal den Begriff der referenziernden Garbage Collection gehört?
Würde mich wundern. Google hat davon jedenfalls auch noch nichts gehört.
-
Du meinst den GroßVater der Garbage Collection, oder? (Referenzen zählen)
Und im Zusammenhang?
-
Stell doch mal einen der "sehr neuartigen" Teile deiner Sprache vor!?
-
Wer Interesse bei mir per email meldet, dem kann ich mehr verraten.
-
gorgoyle schrieb:
Wer Interesse bei mir per email meldet, dem kann ich mehr verraten.
Mach ne Webseite. Oder ist die Sprache geheim? Wenn ja, was erhoffst du dir davon?
-
Ich muß mein Projekt nicht hier öffentlich diskutieren
und kann jetzt auch jedem davon dringend abraten.Mich würde mehr interessieren warum mein Projekt
nicht im Forum Projekte steht? Hat sich der Begriff
Projekt in den letzten 48 Stunden irgendwie geändert?Das ist etwas wofür ich noch keine Begründung gehört habe!
Warum bitte schön wurde mein Thread in dieses Forum verschoben?
Gibt es dafür eine sachliche Erklärung die man hören darf?