[PHP] Checken of een regular expression goed is qua syntax

[Verwijderd]

Zoals het subject zegt! Is er iemand die weet hoe ik in PHP kan checken of de syntax van een PCRE (perl compatible regular expression) goed is?

[NMe]

http://regexlib.com/RETester.aspx

Testen is verder gewoon een kwestie van de regexp aangeven in een string, daarna proberen te matchen op een grotere string, en het resultaat-array afdrukken. Is toch niet zo moeilijk te bedenken?

[ Voor 76% gewijzigd door NMe op 25-11-2004 00:36 ]

[Verwijderd]

-NMe- schreef op donderdag 25 november 2004 @ 00:35:
http://regexlib.com/RETester.aspx

Testen is verder gewoon een kwestie van de regexp aangeven in een string, daarna proberen te matchen op een grotere string, en het resultaat-array afdrukken. Is toch niet zo moeilijk te bedenken?

Het gaat er niet om dat ik mijn eigen expressions wil testen. Dat kan inderdaad wel met zo'n site.

Het gaat erom dat mensen in een toepassing van mij regexps moeten kunnen toevoegen aan een lijst. Er mogen GEEN foute regexps in terecht komen dus moeten ze getest worden op syntax.

Ik weet wel dat je gewoon kan proberen of ie werkt en zien of je een error krijgt maar daarmee kom ik er dus niet. Ik moet iets zien te maken in de trant van een functie die je kunt gebruiken a la:

code:

if(testregexp($een_willekeurige_regexp))  {
  // goed
  // code...
  }
else  {
  // fout
  // code...
  }

Dit alles ZONDER dat er een Warning / Fatal Error verschijnt.

[Verwijderd]

Dat kan eenvoudig door de fout die wel verschijnt af te vangen:

PHP:

  $g_reOk = false;

  function _hdl($errno, $errstr) {
    global $g_reOk;

    $g_reOk = false;
  }

  function checkRegEx($re) {
    global $g_reOk;

    $g_reOk = true;

    set_error_handler("_hdl");
    preg_match($re, "");
    restore_error_handler();

    return $g_reOk;
  }

  echo checkRegEx("|d");

[NMe]

Wat heeft die global nog voor nut als je hem toch overal returnt?

[Breuls]

-NMe- schreef op donderdag 25 november 2004 @ 01:35:
Wat heeft die global nog voor nut als je hem toch overal returnt?

In de error handler return je 'm niet, maar dat is wel de plek waar je wilt dat-ie op false gezet kan worden, zodat je kunt zien of het fout is gegaan of niet.

[Alex]

Breuls schreef op donderdag 25 november 2004 @ 07:18:
[...]

In de error handler return je 'm niet, maar dat is wel de plek waar je wilt dat-ie op false gezet kan worden, zodat je kunt zien of het fout is gegaan of niet.

Dan blijft het alsnog ugly code.
Ik zou dat net ietjes efficiënter aanpakken door de error handler de error uit te laten printen. Nog mooier is om van de hele zwik een objectje te maken. Dan weet je tenminste echt waa je mee bezig bent....

[Verwijderd]

Ik vind hem prima! It does the job en dat telt. Mijn dank is groot!

[Verwijderd]

Verwijderd schreef op donderdag 25 november 2004 @ 10:15:
Ik vind hem prima! It does the job en dat telt. Mijn dank is groot!

Waardeloos! argument, maarja als jij er mee kunt leven

[Verwijderd]

Nu voel ik me toch geroepen mijn code te verdedigen tegen verbale aanvallen van snoodaards. Maar niet al te enthousiast, want ik weet zelf ook wel dat het niet geweldig is (en met die global ben ik ook niet blij).

MAARRR... globals zijn niet per definitie evil. Net zoals eval() niet per definitie evil is en includen op basis van bestandsnaam niet. Het zijn van die dingen waar iedereen meteen van roept "ieks! bleh! ga weg! niet doen!", en imho zonder reden. Als je weet waar je mee bezig bent kan het best.

Het gebruikelijke argument tegen globals is: je weet niet waar ze overal veranderd kunnen worden in je code, en dat kan onverwachte invloeden hebben op het verloop ervan (een branch die ergens de verkeerde kant op gaat bijvoorbeeld). Waarom dat hier imho geen probleem is:

Ten eerste: van deze global blijf je af. Je moet het maar zien als een ADT (maar dan zonder data ) dat geïmplementeerd is met functies. De functie _hdl is in principe net zo smerig, maar daar hoor je dan weer niemand over? Beschouw de global en de handler als `private', en roep dit stuk code alleen aan via de interfacefunctie. Het gedraagt zich zoals je wil.

Ten tweede: zelfs al zou je de waarde van de global ergens anders in de code veranderen (voor wat voor reden dan ook), dan zou de code nog steeds goed blijven werken, omdat er geen aannames gemaakt worden over de staat van de global vooraf en ondertussen krijgt geen code de kans om met de global te knoeien.

Conclusie: het gebruik van de global is misschien niet mooi, maar ik vind het zeker verdedigbaar en wel kunnen.

Alex de Groot schreef op donderdag 25 november 2004 @ 09:16:
[...]
Dan blijft het alsnog ugly code.
Ik zou dat net ietjes efficiënter aanpakken door de error handler de error uit te laten printen.

In hoeverre is dat anders dan geen error handler, als PHP de error uitprint? Verder heeft de TS expliciet gezegd dat hij geen foutmeldig wou. Als je de foutmelding wilt behouden, kun je $errstr ook nog in een global opslaan in de error handler. Uitprinten was echter niet de bedoeling.

Nog mooier is om van de hele zwik een objectje te maken. Dan weet je tenminste echt waa je mee bezig bent....

Dat is tenminste een goed argument. Ja, dat kan, en is waarschijnlijk mooier. Hoewel het je dan wel twee regels code om een re te checken, en nu maar één. Zoals gezegd gedraagt het stuk code zich nu een beetje als object/component, met een interface en een private gedeelte. In PHP win je er niet zoveel mee om het als object te implementeren, omdat je data hiding toch niet kan verplichten.

Maar het stuk code kan eenvoudig gelift worden naar een object, als je dat liever hebt.

Verwijderd schreef op donderdag 25 november 2004 @ 10:20:
[...]
Waardeloos! argument, maarja als jij er mee kunt leven

Dat vind ik nogal een agressieve opmerking. Helaas is het nou eenmaal zo dat in de praktijk niet altijd de meest geweldige code wordt geschreven, maar wordt volstaan met `code die werkt'. Tja, daarvoor zit je in een commerciële omgeving. En ik vraag me af waar `er' hier op wijst... (en `leven').

Ik bedoel overigens niemand tegen de schenen te schoppen en een flamewar te ontketenen; ik wil de zaken gewoon even iets genuanceerder gesteld hebben.