OO-tokenizer implementatie
Door Richard van Velzen, 19 jaar geleden, 4.946x bekeken
Crosspost van PHPFreakz.nl:
Ik zit redelijk vaak te werken met de tokenizer van PHP (token_get_all, token_name), en ik erger me steeds mateloos aan dat ik constant moet kijken of het een array is, of het dit of dat is, enzovoorts.
Ik heb dus een simpele uitwerking hiervan gemaakt, compleet Objectgeoriënteerd, zodat ik het ook makkelijk kan gebruiken in mijn eigen kleine projectjes (denk aan een shortifier of beautifier).
Ik heb een (gigantische) uitwerking van de highlighting in PHP erbij gemaakt als voorbeeld, waaruit dus blijkt wat de kracht hiervan is.
De uitvoer daarvan is overigens XHTML Strict-valid, dus mocht je het willen gebruiken (ik raad het af i.v.m. performance, maar het werkt) zal dat dus geen problemen opleveren.
Anyway, genoeg informatie, uitleg staat grotendeels in de code, vragen/complimenten/opmerkingen (graag)/verbeterpunten (nog liever)/hatemail mag natuurlijk altijd.
Gesponsorde koppelingen
PHP script bestanden
Er zijn 4 reacties op 'Oo tokenizer implementatie'
0 
-0 
-0
Dit ziet er zeer interessant uit, en zo op het oog ook nog goed ook. Ik zal zeker d'r eens een keer mee gaan spelen, maar nu heb ik daar niet zoveel tjid voor.
0 -0
-0
Ziet er zeker heel bruikbaar uit! Zo zou eigenlijk PHP er native al uit moeten zien...
Een paar kleine dingen nog die makkelijker/anders zouden kunnen:
- Regel 97 t/m 101: Je controleert hier d.m.v. de reflectionclass of de doorgegeven class wel een subclass van Token_Abstract. Dit kan gemakkelijker met de operator 'instanceof' (die ook met overerving werkt, en ook strings accepteerd).
- Regel 91 t/m 93 en 95 t/m 97: Hier zet je een NULL value die uit de 'default parameter' komt om in de standaard waarde. Waarom zet je die standaard waarde niet meteen in de 'default parameter'?
- De classes Tokenizer_String en Tokenizer_File bieden geen extra functionaliteit t.o.v. class Tokenizer. Ze zijn eigenlijk alleen een shorthand. Zelf zou ik het zo doen dat Tokenizer_String er uit gaat (en dat Tokenizer zijn taak gewoon overneemt) en dat Tokenizer_File de file zelf uitleest, en die informatie doorgeeft aan zijn parent. Op die manier heb je het volgens mij iets meer OO correct...
- Je zou kunnen overwegen gebruik te maken van een aantal classes en interfaces van SPL. De exceptions en array-classes/interfaces zouden denk ik wel in aanmerking komen. Op die manier heb je de classes iets meer gestandaardiseerd, waardoor mensen er gemakkelijker, zonder de documentatie te lezen mee kunnen werken.
- Ik zou de meeste van je class members in plaats van private een protected eigenschap meegeven. Op die manier hebben (toekomstige) subclasses ook nog toegang tot dit soort variabelen.
Een paar kleine dingen nog die makkelijker/anders zouden kunnen:
- Regel 97 t/m 101: Je controleert hier d.m.v. de reflectionclass of de doorgegeven class wel een subclass van Token_Abstract. Dit kan gemakkelijker met de operator 'instanceof' (die ook met overerving werkt, en ook strings accepteerd).
- Regel 91 t/m 93 en 95 t/m 97: Hier zet je een NULL value die uit de 'default parameter' komt om in de standaard waarde. Waarom zet je die standaard waarde niet meteen in de 'default parameter'?
- De classes Tokenizer_String en Tokenizer_File bieden geen extra functionaliteit t.o.v. class Tokenizer. Ze zijn eigenlijk alleen een shorthand. Zelf zou ik het zo doen dat Tokenizer_String er uit gaat (en dat Tokenizer zijn taak gewoon overneemt) en dat Tokenizer_File de file zelf uitleest, en die informatie doorgeeft aan zijn parent. Op die manier heb je het volgens mij iets meer OO correct...
- Je zou kunnen overwegen gebruik te maken van een aantal classes en interfaces van SPL. De exceptions en array-classes/interfaces zouden denk ik wel in aanmerking komen. Op die manier heb je de classes iets meer gestandaardiseerd, waardoor mensen er gemakkelijker, zonder de documentatie te lezen mee kunnen werken.
- Ik zou de meeste van je class members in plaats van private een protected eigenschap meegeven. Op die manier hebben (toekomstige) subclasses ook nog toegang tot dit soort variabelen.
0 -0
-0
Quote:
- Regel 97 t/m 101: Je controleert hier d.m.v. de reflectionclass of de doorgegeven class wel een subclass van Token_Abstract. Dit kan gemakkelijker met de operator 'instanceof' (die ook met overerving werkt, en ook strings accepteerd).
Je kunt niet met instanceof checken op de naam van een klasse, alleen op een object. ;)
Quote:
- Regel 91 t/m 93 en 95 t/m 97: Hier zet je een NULL value die uit de 'default parameter' komt om in de standaard waarde. Waarom zet je die standaard waarde niet meteen in de 'default parameter'?
Anders moet je iedere keer dat je die parameter over wilt slaan toch weer de originele waarde invullen. Nu kun je gewoon null invoeren, en krijg je gewoon hetzelfde resultaat.
Quote:
- De classes Tokenizer_String en Tokenizer_File bieden geen extra functionaliteit t.o.v. class Tokenizer. Ze zijn eigenlijk alleen een shorthand. Zelf zou ik het zo doen dat Tokenizer_String er uit gaat (en dat Tokenizer zijn taak gewoon overneemt) en dat Tokenizer_File de file zelf uitleest, en die informatie doorgeeft aan zijn parent. Op die manier heb je het volgens mij iets meer OO correct...
Mwa, OO-correct? Dit is correct genoeg, en het is precies zoals je het zegt: het zijn shorthands. Niets meer dan snelle interfaces naar Tokenizer toe, net als Tokenizer::fromString/fromFile.
Quote:
- Je zou kunnen overwegen gebruik te maken van een aantal classes en interfaces van SPL. De exceptions en array-classes/interfaces zouden denk ik wel in aanmerking komen. Op die manier heb je de classes iets meer gestandaardiseerd, waardoor mensen er gemakkelijker, zonder de documentatie te lezen mee kunnen werken.
Ik weet niet, waar zou ik die moeten implementeren? Misschien Iterator en Countable op Tokenizer, verder zou ik het echt niet weten. De exceptions zouden wellicht nog kunnen, daar zal ik nog even naar kijken.
Quote:
- Ik zou de meeste van je class members in plaats van private een protected eigenschap meegeven. Op die manier hebben (toekomstige) subclasses ook nog toegang tot dit soort variabelen.
Klopt, ook daar ga ik nog even naar kijken. Sommige members krijgen een accessor, sommige andere worden protected. Zo kan ik het wat meer achter de schermen houden allemaal. ;)
Dankje voor je feedback, hier kan ik tenminste wat mee. :)
0 -0
-0
Quote:
Mhm, ja kopt nu je het zegt. Ik had de handleiding verkeerd gelezen:-(Je kunt niet met instanceof checken op de naam van een klasse, alleen op een object. ;)
Quote:
Daar is ook wat voor te zeggen, maar het voordeel van gewoon de standaard class moeten invullen is dat het je code duidelijker maakt.Anders moet je iedere keer dat je die parameter over wilt slaan toch weer de originele waarde invullen. Nu kun je gewoon null invoeren, en krijg je gewoon hetzelfde resultaat.
Quote:
Wat OO-correct is, is natuurlijk subjectief. Mijn mening is echter dat het duidelijker is als je de shorthands verandert in classes die echt wat toevoegen. Zo wordt het bijvoorbeeld voor iemand die jouw script nog weer wil extenden ook makkelijker/logischer. Stel dat hij bijvoorbeeld php code uit de database wil halen, en wil analyseren. Dan maakt hij een extra class, en die geeft hij een extend op Tokenizer. Dan heeft hij het hele file-read gebeuren niet nodig, en dit is dan alleen maar verwarrend/meer werk.Mwa, OO-correct? Dit is correct genoeg, en het is precies zoals je het zegt: het zijn shorthands. Niets meer dan snelle interfaces naar Tokenizer toe, net als Tokenizer::fromString/fromFile.
Quote:
Iterator en Countable zijn goede kandidaten inderdaad, maar je zou er ook nog een ArrayAcces in kunnen gooien. Als je dat wil combineren kom je eigenlijk al in de buurt van ArrayIterator of ArrayObject. Nadeel van die twee is dan alleen weer dat je allerlei sorting functies moet defineren, die hier eigenlijk niet van toepassing zijn. Daarom zou ik het houden bij Countable, ArrayAcces en Iterator of IteratorAggregate. En uiteraard kun je spl Excepties gebruiken. Daar ben ik persoonlijk groot fan van:DIk weet niet, waar zou ik die moeten implementeren? Misschien Iterator en Countable op Tokenizer, verder zou ik het echt niet weten. De exceptions zouden wellicht nog kunnen, daar zal ik nog even naar kijken.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu