[Java] Naamgeving interfaces/classes

[Verwijderd]

De Sun standaard voor naamgeving van Java classes dicteert dat het gewone namen zijn, beginnend met een hoofdletter. Ik heb een klein framework gemaakt (voor parsing, wordt open source gemaakt binnenkort) waar een aantal interfaces en classes worden gedefiniëerd.

Momenteel is het framework ingedeeld in 4 packages (pobs, pobs.parser, pobs.action en pobs.directive), binnen elk package kunnen gelijknamige classes voorkomen, elk volgens de Sun standaard genaamd.

Aangezien ik verwacht dat het aantal classes enorm zal groeien (ruim over de 100) zal ik een systeem moeten vinden om de naamgeving beter te ordenen. Momenteel benader ik ze met het volledige packagenaam echter is dit soms wat té veel. Nu gebruikt Swing bijvoorbeeld veel namen die een 'J' als prefix hebben, in mijn geval zou ik bijvoorbeeld 'P' kunnen gebruiken maar dit levert nog steeds problemen op. Kan ik een 2e prefix toevoegen die de package structuur benadrukt?

Hieronder wat voorbeelden hoe de naamgeving (in de usercode) er uit zou kunnen zien, aan jullie de vraag wat de beste methode zou zijn. Wat zijn er nog meer voor methoden te bedenken en moet ik alles in één package stoppen zodat er maar één import nodig is?

Methode 1 (huidig): pobs.Action, pobs.parser.Action, pobs.directive.NoSkip
Methode 2 (Swing): pobs.Action, PAction, PNoSkip
Methode 3 (prefix): PAction, PPAction, PDNoSkip
Methode 3 (lowercase): PAction, PpAction, PdNoSkip

Bij voorbaat dank,
Martijn

[Alarmnummer]

Ik zou persoonlijk nooit een pre of postfix toevoeging doen aan interfaces omdat dit eigelijk de objecten (horen te) zijn waarin je denkt en niet het implementerende object die dan ineens de mooie naam krijgt.

Maar bij een parser maakt het denk ik niet zoveel uit Kijk anders eens bij andere parser generatoren. Sablecc is bv ook een die code genereerd voor de AST. Ze plaatsen een T voor een token, dus TPlus en TIdentifier. Ze plaatsen een P voor iedere productie: dus PExpression en PStatement. En ze plaatsen een A voor een alternatief. Dit vind ik persoonlijk wel een handiger manier van werken.

[ Voor 7% gewijzigd door Alarmnummer op 16-02-2004 14:47 ]

[Verwijderd]

Alarmnummer schreef op 16 februari 2004 @ 14:42:Maar bij een parser maakt het denk ik niet zoveel uit Kijk anders eens bij andere parser generatoren.

Het gaat hier niet om een parsergenerator als meer een parser-"taal", Gebasseerd op het concept van C++ Spirit (spirit.sourceforge.net). Vanaf Java 1.5 zal het operator overloading moeten gaan gebruiken waardoor het mogelijk zal zijn op een EBNF-achtige manier parsers te schrijven, dus zonder generators, compiler-compilers of andere externe programmatuur.

Dit houdt in dat momenteel (en in iets mindere mate bij gebruikmaking van operator overloading) de gebruiker de classnames veelvuldig zal gebruiken. In feite is het gebruik van een packagenaam (= prefix) in de code al afgedwongen puur door het feit dat er een zeer groot aantal classnames zal komen; als je alles zou importeren loop je grote kans andere classnames te "overloaden", vooral gezien de gangbare namen die ik gebruik ("Set", "Or", "Text").

De eisen waarmee ik nu geconfronteerd ben zijn:
- Makkelijk te gebruiken voor de eindprogrammeur; korte en duidelijke namen.
- Vermijden van conflicten met classes in de unnamed package.
- Vermijden van interne conflicten van gelijkgenaamde classes in de packages.

We maken het niet makkelijk

[Alarmnummer]

Verwijderd schreef op 16 februari 2004 @ 15:02:
[...]

Het gaat hier niet om een parsergenerator als meer een parser-"taal", Gebasseerd op het concept van C++ Spirit (spirit.sourceforge.net). Vanaf Java 1.5 zal het operator overloading moeten gaan gebruiken waardoor het mogelijk zal zijn op een EBNF-achtige manier parsers te schrijven, dus zonder generators, compiler-compilers of andere externe programmatuur.

Dit snap ik niet helemaal. M.b.v. ebnf kan ik samen met een parser generator code genereren (de parser dus) die tekst in kan lezen die voldoet aan de in ebnf gecreeerde syntax. Wat doet jouw tool dan precies en in hoeverre is hij anders dan een parser generator? En voor zover ik weet heeft java (helaas) nog geen operator overloading in 1.5.

[edit]
Ik zat net even op de site te struinen, en wat ik eruit begrijp is dat in de taal zelf meteen ebnf opgenomen kan worden. Hmm.. ik weet even niet zo goed wat ik hiervan moet vinden.. use the right tool for the job is het 1e wat bij me opkomt en verder is het jammer als een taal 'besmet' moet worden met dit soort detailgedrag (want dat is grammatica meestal imho) en de grammatica is weer besmet met c++ code. En verder.. wie gebruikt er nog een LL(k) parser generator? LR werkt echt vele malen handiger.

Ik zal ook meteen mbravenboer zijn commentaar er ff bij zetten.

mbravenboer says:

Alarmnummer
LR werkt echt vele malen handiger

SDF niet vergeten natuurlijk.

alarmnummer says

mbravenboer
SDF niet vergeten natuurlijk

Dan moeten ze wel eens een keer komen met een tool die makkelijk te gebruiken is zonder *nix en zonder dat je tig andere tools moet installeren

mbravenboer
Daar moet ik je gelijk in geven

[ Voor 52% gewijzigd door Alarmnummer op 16-02-2004 16:15 ]

[Verwijderd]

Alarmnummer schreef op 16 februari 2004 @ 16:00:Dit snap ik niet helemaal. M.b.v. ebnf kan ik samen met een parser generator code genereren (de parser dus) die tekst in kan lezen die voldoet aan de in ebnf gecreeerde syntax. Wat doet jouw tool dan precies en in hoeverre is hij anders dan een parser generator? En voor zover ik weet heeft java (helaas) nog geen operator overloading in 1.5.

Het verschil is dat mijn tool (geen tool maar een framework van classes en interfaces dus) geen externe parser generator is. Voordeel hiervan is dat het voor de programmeur erg makkelijk te gebruiken is; geen makefiles of andere "ingewikkelde" compilatiestappen en dat een parser in runtime gemaakt en aangepast kan worden. Er zijn nog wel meer voordelen maar als het straks op Sourceforge staat kan je zelf zien, maar voor het op SF staat moet ik éérst een beetje praktische en gestandaardiseerde classnames hebben Kan je de code wel opsturen als je interesse hebt hoor.

Overigens zou 1.5 (release ergens halverwege dit jaar) dus zowel operator overloading als generics moeten krijgen volgens Sun.

[Alarmnummer]

Verwijderd schreef op 16 februari 2004 @ 16:16:
[...]

Het verschil is dat mijn tool (geen tool maar een framework van classes en interfaces dus) geen externe parser generator is. Voordeel hiervan is dat het voor de programmeur erg makkelijk te gebruiken is; geen makefiles of andere "ingewikkelde" compilatiestappen en dat een parser in runtime gemaakt en aangepast kan worden.

Ik ben het voor mijn eigen systemen nog nooit nodig geweest dat runtime de syntax nog aangespast kan worden. Hoe moet je het dan ook nog eens runtime semantisch gaan controleren, laat staan verder bewerken? Het kan ook zijn dat ik de mogelijkheden niet zie omdat ik er nog nooit op deze manier naar heb gekeken.

Kan je de code wel opsturen als je interesse hebt hoor.

Mijn email adres staat bij mijn profile

Overigens zou 1.5 (release ergens halverwege dit jaar) dus zowel operator overloading als generics moeten krijgen volgens Sun.

Ik ben redelijk up to date met wat er in 1.5 komt, maar ik heb nergens gezien dat operator overloading erin komt. Heb je er misschien een link van?

[Alarmnummer]

alhoewel het niet mijn topic is, kick ik hem nog wel ff

[Verwijderd]

Alarmnummer schreef op 16 februari 2004 @ 16:23:Mijn email adres staat bij mijn profile

Heb 't geupload naar http://www.vanderlee.com/crips/repository/pobs.jar

Ik ben redelijk up to date met wat er in 1.5 komt, maar ik heb nergens gezien dat operator overloading erin komt. Heb je er misschien een link van?

Inderdaad, kon het ook niet vinden bij nader onderzoek. Maakt verder niet uit, de huidige versie blijft nog steeds in mijn ogen praktisch en nuttig.

[Alarmnummer]

Verwijderd schreef op 17 februari 2004 @ 20:12:
[...]

Heb 't geupload naar http://www.vanderlee.com/crips/repository/pobs.jar

Ik zal er vandaag of morgen even naar kijken.

Inderdaad, kon het ook niet vinden bij nader onderzoek. Maakt verder niet uit, de huidige versie blijft nog steeds in mijn ogen praktisch en nuttig.

Ik zou zelf ook graag zien dat het erin komt. En dan hoeft het niet zo te zijn die je bijna iedere operator mag overloaden zoals bij c++, maar alleen een beperkt aantal zoals bv alle rekenkundige ed. Ik denk dat dat de syntax wel een heel stuk leesbaarder kan maken, en hetzelfde geld voor property syntax.