In welchen Namespace?

[shorty]

Tach die Damen und Herren,

ich stehe mal wieder vor der Frage: "Wie soll ich das Package bezeichnen, in welchem Namensraum macht es am meisten Sinn?" Es geht um ein Parser/Serialization Framework, welches aktuell wie folgt aufgebaut ist:

com.shortybmc.data.parser.*



Erstens stellt sich mir die Frage, ob ich es in den Namespace parser, oder serialization stecken soll. Auf serialization bin ich übrigens nur gekommen, weil Adobe seinen JSON Encoder/Decoder in eben jenen verfrachtet hat. Schaue ich auf Wiki, oder sonstwo finden sich folgende Erklärungen für

• Parser
• Serialization

Ich für meinen Teil finde Parser am passendsten. Was sagt ihr?



Zweitens, ebenfalls inspiriert durch die Adobe corelib Architektur, bleibt noch die Frage

com.shortybmc.data.(parser|serialization).*

oder

com.shortybmc.(parser|serialization).*

Aktuell ist es unterhalb von data abgelegt, wie in vielen Java, Perl oder C Code-Archiven. Finde ich auch am schicksten. Was sagt ihr?



Drittens suche ich noch einen Namen für das Projekt. Actionscript Parser and Serialization Framework is etwas lang. APSF sieht blöd aus und hört sich sch... an.

Ich bin da völlig überfragt. Sowas wie ein Codename wäre schon schön, so das ich den Zusatz "Actionscript Parser and Serialization Framework" noch weiter nutzen kann. Namenskonventionen:

• nur kleinbuchstaben [a-z], keine zahlen, sonderzeichen, whitespace, unter/bindestriche

Vorschläge?


lg,
shorty

[Omega Psi]

1. Hängt davon ab, ob du einen Parser programmierst oder einen Serilisierer. Wenn du umschreiben könntest was passiert, wäre das vielleicht hilfreich.
2. data würde ich verwenden, wenn d Datentypen erstellst, die Rohdaten kapseln. Dann aber sogar lieber datatypes. Bei deinem Projekt scheint es aber diese Datentypen nicht zu geben, deswegen würde ich sie weglassen. Da sollte com.shortybmc.assf.(parser|serialization).* ausreichen. Ich habe aber den Projektnamen mal eingeführt. Das hilft besser zu differenzieren und so kannst du auch gleiche Klassennamen in verschiedenen Projekten verwenden.
3. Auch hier muss ich mal nachfragen, was parst du und wie serialisierst du die Daten?

[shorty]

War wohl etwas spät gester/heute. Guten morgen omega

Zu 1. Ich werde unterhalb von data noch ein package serialization erstellen. Für mich war bis vor 10 Minuten parser/serialisieren das gleiche. Damit hat sich Frage eins und zwei erledig.

Zu 2. Hmmm, also von projektnamen im package/classpath halte ich eigentlich überhaupt nichts. Obgleich das zur eindeutigen identifizierung mit sicherheit nicht falsch wäre. In anbetracht der tatsache das datentypen noch hinzu kommen, werde ich data beibehalten, aka.

com.shortbmc.data
com.shortbmc.data.types
com.shortbmc.data.parser
com.shortbmc.data.serialization

In data.types werden die fertigen implementierungen hinterlegt, bezeichnet durch den Datei-Suffix, z.B. data.types.CSV. Diese implementieren dann zum beispiel den jeweilg zugehörigen parser und weitere methoden zum laden, senden or what ever. Danke für den tipp mit den datentypen omega!

Zu 3. Anfangen wollte ich mit simplen Flatfile-parsern, also .csv, .cfg, .ini, oder was es sonst noch so gibt. Hauptsächliches augenmerk liegt für mich jedoch darauf, endlich die passenden rahmenbedingugen für klassen dieser art zu schaffen, denn immer wenn ich mal wieder einen parser schreibe, und das sind aktuell nicht wenige (as2), sinniere ich wieder darüber nach wie ich sie benenne, wo ich sie hin tue und wie ich sie implemetiere. Die ganzen as2 varianten sehen nicht nur unterschiedlich aus, sondern haben auch alle unterschiedliche methoden bezeichner für aktionen die sie alle gemein haben. Du glaubst gar nicht was da bei mir für ausgefallene bezeichner existieren


lg,
shorty
... und danke nochmal für die rasche antwort

[Omega Psi]

Ja du, kein Ding

Klingt aber vernünftig, wie du es machst. So kann man es machen.

Gruß

[shorty]

Wenn das für dich ok ist, dann mache ich das jetzt auch so! Hört sich nämlich alles recht schlüßig an.

Bleibt nur noch die frage nach dem projektnamen. Nich weil ich ihn ins package integrieren möchte, sonder weil ich auf google code/projects diesen verwenden will. Ich bin schon fast soweit es einfach

Title APSF
Subtitle "Actionscript Parser and Serialization Framework"

zu nennen

Die frage deshalb, weil man den Projektnamen, also den title "APSF", einmal angegeben nicht wieder ändern kann.



Gruß²

[Omega Psi]

Vielleicht könnte man in den Namen einbringen wofür das Framework genutzt werden kann und nicht, was für Komponenten genutzt werden können (Parser und Serialisierer) denn diese finden sich ja eh in vielen Frameworks.

Vielleicht ein Ansatz?

[shorty]

... da mache ich mir mal auf dem weg zur arbeit gedanken drüber