Formale Fragen um BMax Programmierung

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	Kernle 32DLL Betreff: Formale Fragen um BMax Programmierung	So, Jun 21, 2009 22:05 Antworten mit Zitat
Hiho, Es gibt ein paar Dinge bezüglich des Programmierstils, mit denen ich mich schon seit längerem beschäftige. Einige Dinge treffen exklusiv auf BlitzMax zu, deshalb stelle ich die Fragen auch hier, die meisten sollten aber generell gelten. Na dann lege ich mal los 1. Debugging gelöst (reflections sind ideal) Ich bin schon länger am nachdenken wie ich eine vernünftige, vom Enduser steuerbare, Möglichkeit zum Debugging implementieren könnte. Bzw. im nächsten Schritt, wie die Ausgabe selbiger Informationen aussehen könnte. Meine bisherigen Gedanken führten mich zu keinem vernünftigen Ergebnis. Aber meine bisherigen Gedanken gingen in etwa die Richtung: Alle Klassen die ich habe, sind extends von einer Basis-Debug-Klasse. Somit habe ich die Möglichkeit jeder Instanz jeder Klasse mithilfe von Deugfunktionen zu kontrollieren. Ggf. lässt sich auch über Globals der Basisklasse etwas realisieren. Mein Problem ist nur, das die entsprechenden Funktionen auf die einzelnen Klassen (automatisch oder manuell) abgestimmt werden müssten (im hinblick auf Felder, usw.) 2. Fehlerabfangen Bevor jetzt die ersten Throw/Try/Catch schreien, es geht sich um etwas anderes. Generell geht es darum wie eine Funktion, die mit falschen Parametern gefüttert wird, reagieren soll. Ich habe noch nicht analysiert wie die BMax std. Funktionen reagieren, aber ich habe im Kopf das die B3D Funktionen einfach Runtimeerror ausgeben ala "Mesh does not exist". Warum mache ich mir Gedanken darüber? Mein programmierstil lässt sehr viel Spielraum für Fehler. Bzw. genauer, ich hantiere sehr viel mit Instanzen rum. Z.b. hat eine Einheit Zeiger auf eine Einheiten-Typ Instanz, eine Spieler Instanz, usw. Meine Gedanken drehen sich vor allem um die Funktionen (Methoden) zur erstellen von den Instanzen. Es gibt da ein paar Situationen, zu denen ich gerne eure Meinung wüsste: a) Ich habe einen Spieler mit dem Namen "Hans". Jetzt soll ein neuer Spieler erstellt werden, der auch "Hans" heißen soll. Was soll geschehen? Ein Throw ala "Playername in-use"? Einfach ein handle auf den bereits exestierenden Spieler zurück geben? Einfach Null zurück geben? b) Eine Einheit wird korrekt erstellt, aber dann wird einfach die mit ihr verknüpfte "EinheitenTyp" Instanz gelöscht. Was soll passieren? Ich kann nicht in jeder Funktion der Einheit die auf den Einheitentyp zugreifen würde eine Abfrage machen ob der Einheitentyp noch exestiert. Das würde zuviel Rechenzeit kosten. 3. Throws benennen Eigentlich eine simple Sache, und wohl auch etwas Geschmackssache. Wie bennene ich meine Throws richtig? Ich habe dazu keine Meinung, und bin für alles offen. Aber ein Gedankenanstoß ist u.a. ob man ähnliche Arten von Throws (Throw für eine Null-Instanz / Throw für eine ungültige Instanz) gruppieren, oder auseinander halten sollte. Im normalfall läuft es eh aufs gleiche hinaus, oder? 4. Validätsprüfung von Instanzen - Dieser Abschnitt wurde soeben gelöscht da ich die Lösung selber gefunden habe - 5. Verschachtelung Ich will eigentlich das bestimmte Teile meiner "Engine" (wenn man mein Codemüll so nennen kann ^^) unabhängig voneinander arbeiten. In Wirklichkeit läuft aber alles darauf hinaus, das alles irgendwie voneinander abhängig ist, und ich ein riesiges misslungens Gebilde habe, bei dem ein kleiner Fehler sofots kollabiert. Ein Beispiel dazu ist folgende Situation: Die Funktion zur erstellung einer VersionsInstanz funktioniert nicht. Ohne Instanz kein VersionsBundle. Ohne VersionsBundle keine GameMod. Ohne GameMod keine UnitTypes. Ohne EinheitenTypen keine Einheiten. Man sieht, ein kleiner Fehler sorgt dafür das nichts funktioniert. Was sind eure Gedanken dazu? Wieviel verschachtelung ist okay, und was ist einfach unnötig? Bzw wie tollerant sollte man sein? Ich hoffe ihr könnt mir mit diesen Dingen helfen, da ich selber mit keine eigene Meinung bilden kann. Ich weiß, das meiste davon ist pure Geschmackssache, aber ich will so "sauber" wie möglich arbeite, damit ich a) Immer den Überblick behalte, b) Sofern eines meiner Projekte mal zu Teamprojekten werden sollte die Einarbeitungszeit minimal ist, da alles quasi "genormt" ist und c) bei einer möglichen Veröffentlichung des Codes die generelle Einarbeitungszeit kürzer ist (quasi wie b) So long, Kernle

Kernle 32DLL

Betreff: Formale Fragen um BMax Programmierung

So, Jun 21, 2009 22:05
Antworten mit Zitat

Hiho,

Es gibt ein paar Dinge bezüglich des Programmierstils, mit denen ich mich schon seit längerem beschäftige. Einige Dinge treffen exklusiv auf BlitzMax zu, deshalb stelle ich die Fragen auch hier, die meisten sollten aber generell gelten. Na dann lege ich mal los Wink

1. Debugging gelöst (reflections sind ideal)
Ich bin schon länger am nachdenken wie ich eine vernünftige, vom Enduser steuerbare, Möglichkeit zum Debugging implementieren könnte. Bzw. im nächsten Schritt, wie die Ausgabe selbiger Informationen aussehen könnte. Meine bisherigen Gedanken führten mich zu keinem vernünftigen Ergebnis. Aber meine bisherigen Gedanken gingen in etwa die Richtung:

Alle Klassen die ich habe, sind extends von einer Basis-Debug-Klasse. Somit habe ich die Möglichkeit jeder Instanz jeder Klasse mithilfe von Deugfunktionen zu kontrollieren. Ggf. lässt sich auch über Globals der Basisklasse etwas realisieren. Mein Problem ist nur, das die entsprechenden Funktionen auf die einzelnen Klassen (automatisch oder manuell) abgestimmt werden müssten (im hinblick auf Felder, usw.)

2. Fehlerabfangen
Bevor jetzt die ersten Throw/Try/Catch schreien, es geht sich um etwas anderes. Generell geht es darum wie eine Funktion, die mit falschen Parametern gefüttert wird, reagieren soll. Ich habe noch nicht analysiert wie die BMax std. Funktionen reagieren, aber ich habe im Kopf das die B3D Funktionen einfach Runtimeerror ausgeben ala "Mesh does not exist". Warum mache ich mir Gedanken darüber? Mein programmierstil lässt sehr viel Spielraum für Fehler. Bzw. genauer, ich hantiere sehr viel mit Instanzen rum. Z.b. hat eine Einheit Zeiger auf eine Einheiten-Typ Instanz, eine Spieler Instanz, usw.

Meine Gedanken drehen sich vor allem um die Funktionen (Methoden) zur erstellen von den Instanzen. Es gibt da ein paar Situationen, zu denen ich gerne eure Meinung wüsste:

a) Ich habe einen Spieler mit dem Namen "Hans". Jetzt soll ein neuer Spieler erstellt werden, der auch "Hans" heißen soll. Was soll geschehen? Ein Throw ala "Playername in-use"? Einfach ein handle auf den bereits exestierenden Spieler zurück geben? Einfach Null zurück geben?

b) Eine Einheit wird korrekt erstellt, aber dann wird einfach die mit ihr verknüpfte "EinheitenTyp" Instanz gelöscht. Was soll passieren? Ich kann nicht in jeder Funktion der Einheit die auf den Einheitentyp zugreifen würde eine Abfrage machen ob der Einheitentyp noch exestiert. Das würde zuviel Rechenzeit kosten.

3. Throws benennen
Eigentlich eine simple Sache, und wohl auch etwas Geschmackssache. Wie bennene ich meine Throws richtig? Ich habe dazu keine Meinung, und bin für alles offen. Aber ein Gedankenanstoß ist u.a. ob man ähnliche Arten von Throws (Throw für eine Null-Instanz / Throw für eine ungültige Instanz) gruppieren, oder auseinander halten sollte. Im normalfall läuft es eh aufs gleiche hinaus, oder?

4. Validätsprüfung von Instanzen
- Dieser Abschnitt wurde soeben gelöscht da ich die Lösung selber gefunden habe -

5. Verschachtelung
Ich will eigentlich das bestimmte Teile meiner "Engine" (wenn man mein Codemüll so nennen kann ^^) unabhängig voneinander arbeiten. In Wirklichkeit läuft aber alles darauf hinaus, das alles irgendwie voneinander abhängig ist, und ich ein riesiges misslungens Gebilde habe, bei dem ein kleiner Fehler sofots kollabiert. Ein Beispiel dazu ist folgende Situation:

Die Funktion zur erstellung einer VersionsInstanz funktioniert nicht. Ohne Instanz kein VersionsBundle. Ohne VersionsBundle keine GameMod. Ohne GameMod keine UnitTypes. Ohne EinheitenTypen keine Einheiten. Man sieht, ein kleiner Fehler sorgt dafür das nichts funktioniert.

Was sind eure Gedanken dazu? Wieviel verschachtelung ist okay, und was ist einfach unnötig? Bzw wie tollerant sollte man sein?

Ich hoffe ihr könnt mir mit diesen Dingen helfen, da ich selber mit keine eigene Meinung bilden kann. Ich weiß, das meiste davon ist pure Geschmackssache, aber ich will so "sauber" wie möglich arbeite, damit ich a) Immer den Überblick behalte, b) Sofern eines meiner Projekte mal zu Teamprojekten werden sollte die Einarbeitungszeit minimal ist, da alles quasi "genormt" ist und c) bei einer möglichen Veröffentlichung des Codes die generelle Einarbeitungszeit kürzer ist (quasi wie b)

So long,
Kernle

Zuletzt bearbeitet von Kernle 32DLL am So, Jun 21, 2009 22:52, insgesamt einmal bearbeitet

	Artemis Betreff: Re: Formale Fragen um BMax Programmierung	So, Jun 21, 2009 22:25 Antworten mit Zitat
Zitat: 1. Debugging Ich bin schon länger am nachdenken wie ich eine vernünftige, vom Enduser steuerbare, Möglichkeit zum Debugging implementieren könnte. Bzw. im nächsten Schritt, wie die Ausgabe selbiger Informationen aussehen könnte. Meine bisherigen Gedanken führten mich zu keinem vernünftigen Ergebnis. Aber meine bisherigen Gedanken gingen in etwa die Richtung: Alle Klassen die ich habe, sind extends von einer Basis-Debug-Klasse. Somit habe ich die Möglichkeit jeder Instanz jeder Klasse mithilfe von Deugfunktionen zu kontrollieren. Ggf. lässt sich auch über Globals der Basisklasse etwas realisieren. Mein Problem ist nur, das die entsprechenden Funktionen auf die einzelnen Klassen (automatisch oder manuell) abgestimmt werden müssten (im hinblick auf Felder, usw.) Wenn du z.B. die Informationen über die Klasse oder über ein Objekt haben willst könnte BRL.Reflection etwas für dich sein (hab damit noch nicht gearbeitet, meine aber, dass das in die Richtung geht) Zitat: 2. Fehlerabfangen Bevor jetzt die ersten Throw/Try/Catch schreien, es geht sich um etwas anderes. Generell geht es darum wie eine Funktion, die mit falschen Parametern gefüttert wird, reagieren soll. Ich habe noch nicht analysiert wie die BMax std. Funktionen reagieren, aber ich habe im Kopf das die B3D Funktionen einfach Runtimeerror ausgeben ala "Mesh does not exist". Warum mache ich mir Gedanken darüber? Mein programmierstil lässt sehr viel Spielraum für Fehler. Bzw. genauer, ich hantiere sehr viel mit Instanzen rum. Z.b. hat eine Einheit Zeiger auf eine Einheiten-Typ Instanz, eine Spieler Instanz, usw. Das kommt immer darauf an, 1. wie fehlertolerant dein Programm sein soll und 2. wie fehlertolerant es dann wirklich ist. Denn es macht keinen Sinn, in Funktionen immer Exceptions zu werfen, wenn die im Programm nicht ausgewertet werden. Es kommt darauf an, wie und ob du die Exceptions auswertest. Zitat: a) Ich habe einen Spieler mit dem Namen "Hans". Jetzt soll ein neuer Spieler erstellt werden, der auch "Hans" heißen soll. Was soll geschehen? Ein Throw ala "Playername in-use"? Einfach ein handle auf den bereits exestierenden Spieler zurück geben? Einfach Null zurück geben? Kommt auf die Situation an. Wenn es nur einen Spieler mit einem Namen geben soll, dann würde ich natürlich entweder einen vordefinierten Wert zurückgeben oder eine DoublePlayerNameException werfen, damit das abgefangen werden kann und man die Möglichkeit einer Zweiteingabe hat. Wie gesagt, es ist absolut von dem Szenario abhängig. Zitat: b) Eine Einheit wird korrekt erstellt, aber dann wird einfach die mit ihr verknüpfte "EinheitenTyp" Instanz gelöscht. Was soll passieren? Ich kann nicht in jeder Funktion der Einheit die auf den Einheitentyp zugreifen würde eine Abfrage machen ob der Einheitentyp noch exestiert. Das würde zuviel Rechenzeit kosten. Hier ist die Frage, warum kann dieses Objekt, von dem das Oberobjekt abhängig ist, gelöscht werden? Vielleicht liegt hier ja ein Designfehler? Ansonsten wäre vielleicht das Observer-Pattern das richtige für dich. Das Objekt meldet einfach seinem Oberobjekt, dass es gelöscht wurde. Zitat: 5. Verschachtelung Ich will eigentlich das bestimmte Teile meiner "Engine" (wenn man mein Codemüll so nennen kann ^^) unabhängig voneinander arbeiten. In Wirklichkeit läuft aber alles darauf hinaus, das alles irgendwie voneinander abhängig ist, und ich ein riesiges misslungens Gebilde habe, bei dem ein kleiner Fehler sofots kollabiert. Ein Beispiel dazu ist folgende Situation: Die Funktion zur erstellung einer VersionsInstanz funktioniert nicht. Ohne Instanz kein VersionsBundle. Ohne VersionsBundle keine GameMod. Ohne GameMod keine UnitTypes. Ohne EinheitenTypen keine Einheiten. Man sieht, ein kleiner Fehler sorgt dafür das nichts funktioniert. Warum sind die Sachen so abhängig, dass das ganze wegen einer Funktion kollabiert? So generell kann man, meiner Meinung, da nicht so viel zu sagen.

Artemis

Betreff: Re: Formale Fragen um BMax Programmierung

So, Jun 21, 2009 22:25
Antworten mit Zitat

Zitat:

1. Debugging
Ich bin schon länger am nachdenken wie ich eine vernünftige, vom Enduser steuerbare, Möglichkeit zum Debugging implementieren könnte. Bzw. im nächsten Schritt, wie die Ausgabe selbiger Informationen aussehen könnte. Meine bisherigen Gedanken führten mich zu keinem vernünftigen Ergebnis. Aber meine bisherigen Gedanken gingen in etwa die Richtung:

Alle Klassen die ich habe, sind extends von einer Basis-Debug-Klasse. Somit habe ich die Möglichkeit jeder Instanz jeder Klasse mithilfe von Deugfunktionen zu kontrollieren. Ggf. lässt sich auch über Globals der Basisklasse etwas realisieren. Mein Problem ist nur, das die entsprechenden Funktionen auf die einzelnen Klassen (automatisch oder manuell) abgestimmt werden müssten (im hinblick auf Felder, usw.)

Wenn du z.B. die Informationen über die Klasse oder über ein Objekt haben willst könnte BRL.Reflection etwas für dich sein (hab damit noch nicht gearbeitet, meine aber, dass das in die Richtung geht)

Zitat:

2. Fehlerabfangen
Bevor jetzt die ersten Throw/Try/Catch schreien, es geht sich um etwas anderes. Generell geht es darum wie eine Funktion, die mit falschen Parametern gefüttert wird, reagieren soll. Ich habe noch nicht analysiert wie die BMax std. Funktionen reagieren, aber ich habe im Kopf das die B3D Funktionen einfach Runtimeerror ausgeben ala "Mesh does not exist". Warum mache ich mir Gedanken darüber? Mein programmierstil lässt sehr viel Spielraum für Fehler. Bzw. genauer, ich hantiere sehr viel mit Instanzen rum. Z.b. hat eine Einheit Zeiger auf eine Einheiten-Typ Instanz, eine Spieler Instanz, usw.

Das kommt immer darauf an, 1. wie fehlertolerant dein Programm sein soll und 2. wie fehlertolerant es dann wirklich ist.
Denn es macht keinen Sinn, in Funktionen immer Exceptions zu werfen, wenn die im Programm nicht ausgewertet werden. Es kommt darauf an, wie und ob du die Exceptions auswertest.

Zitat:

a) Ich habe einen Spieler mit dem Namen "Hans". Jetzt soll ein neuer Spieler erstellt werden, der auch "Hans" heißen soll. Was soll geschehen? Ein Throw ala "Playername in-use"? Einfach ein handle auf den bereits exestierenden Spieler zurück geben? Einfach Null zurück geben?

Kommt auf die Situation an.
Wenn es nur einen Spieler mit einem Namen geben soll, dann würde ich natürlich entweder einen vordefinierten Wert zurückgeben oder eine DoublePlayerNameException werfen, damit das abgefangen werden kann und man die Möglichkeit einer Zweiteingabe hat.
Wie gesagt, es ist absolut von dem Szenario abhängig.

Zitat:

b) Eine Einheit wird korrekt erstellt, aber dann wird einfach die mit ihr verknüpfte "EinheitenTyp" Instanz gelöscht. Was soll passieren? Ich kann nicht in jeder Funktion der Einheit die auf den Einheitentyp zugreifen würde eine Abfrage machen ob der Einheitentyp noch exestiert. Das würde zuviel Rechenzeit kosten.

Hier ist die Frage, warum kann dieses Objekt, von dem das Oberobjekt abhängig ist, gelöscht werden?
Vielleicht liegt hier ja ein Designfehler?
Ansonsten wäre vielleicht das Observer-Pattern das richtige für dich. Das Objekt meldet einfach seinem Oberobjekt, dass es gelöscht wurde.

Zitat:

5. Verschachtelung
Ich will eigentlich das bestimmte Teile meiner "Engine" (wenn man mein Codemüll so nennen kann ^^) unabhängig voneinander arbeiten. In Wirklichkeit läuft aber alles darauf hinaus, das alles irgendwie voneinander abhängig ist, und ich ein riesiges misslungens Gebilde habe, bei dem ein kleiner Fehler sofots kollabiert. Ein Beispiel dazu ist folgende Situation:

Die Funktion zur erstellung einer VersionsInstanz funktioniert nicht. Ohne Instanz kein VersionsBundle. Ohne VersionsBundle keine GameMod. Ohne GameMod keine UnitTypes. Ohne EinheitenTypen keine Einheiten. Man sieht, ein kleiner Fehler sorgt dafür das nichts funktioniert.

Warum sind die Sachen so abhängig, dass das ganze wegen einer Funktion kollabiert? So generell kann man, meiner Meinung, da nicht so viel zu sagen.

	beanage.johannes	So, Jun 21, 2009 23:38 Antworten mit Zitat
was für eine engine solls den werden?

beanage.johannes

So, Jun 21, 2009 23:38
Antworten mit Zitat

was für eine engine solls den werden?

	HackerBoyZ	Mo, Jun 22, 2009 23:14 Antworten mit Zitat
zu 5. du meinst das teile als eigene prozesse laufen sllen? wenn ja dann schau dir mal SharedMemory an

HackerBoyZ

Mo, Jun 22, 2009 23:14
Antworten mit Zitat

zu 5.

du meinst das teile als eigene prozesse laufen sllen?
wenn ja dann schau dir mal SharedMemory an