[PHP] $var mag alleen letters bevatten

[Verwijderd]

heb me rotgezocht maar kan over dit simpele ding echt niks vinden. het het ooit eerder gedaan maar weet het niet meer . ik wil kijken of een $var alleen letters bevat (dus geen cijfers, spaties, andere tekens) maar hoe doe ik dat nou ook al weer?

[GraasGast]

/[a-zA-Z]*/

[simon]

Have phun: http://nl2.php.net/eregi

[Verwijderd]

zo ver was ik ook al, alleen ik weet niet hoe ik /[a-zA-Z]*/ met erigi combineer?
dan kijkt hij toch alleen of de $va a-z of A-Z bevat. dan zou hij 2A goed moeten rekenen omdat er A inzit???

[simon]

PHP:

<?php
if (eregi("/[a-zA-Z]*/", $string)) {
    echo "Je string bevat letters.."
}
?>

wordt het... Toch niet zo moeilijk? Misschien kun je even in de rest van de php.net man pages duiken die er zijn

Desnoods:
http://nl2.php.net/manual/nl/function.preg-match.php

[ Voor 20% gewijzigd door simon op 25-07-2003 15:58 ]

[Limhes]

Simon schreef op 25 juli 2003 @ 15:57:

PHP:

<?php
if (eregi("/[a-zA-Z]*/", $string)) {
    echo "Je string bevat letters.."
}
?>

wordt het... Toch niet zo moeilijk? Misschien kun je even in de rest van de php.net man pages duiken die er zijn

Desnoods:
http://nl2.php.net/manual/nl/function.preg-match.php

PHP:

<?php
if (eregi("^[a-z]*$", $string))
{
    echo "Je string bevat <b>alleen</b> letters.."
}
?>

Want: eregi is van zichzelf al case-insensitive, jouw regexp was van het PCRE-type en hij wil alléén maar letters...

edit:
quote toegevoegd...

[ Voor 58% gewijzigd door Limhes op 25-07-2003 16:03 ]

[Soultaker]

Erm, ok. Lijkt me dat GraasGast en Simon opnieuw mogen leren lezen.

On-topic: je wil aangeven dat er tussen het begin en het einde van de string niets dan karakters zitten. Daarvoor moet je de tokens gebruiken die het begin en het einde van de string matchen: ^ en $. De uiteindelijke check wordt dus zoiets:

PHP:

ereg('^[[:alpha:]]*$', $string);

Gebruik alleen character ranges als je echt op specifieke karakters (a, b,c, ..., z) wilt controleren, want veel talen kennen ook andere letters (ë, etcetera) die niet in deze range zitten. Het gebruik van een POSIX character class (zoals [[:alpha:]] voor alfabetische karakters) is veiliger en makkelijker, want je hoeft dan gelijk geen onderscheid meer te maken tussen hoofdletters en kleine letters (en kan dus gewoon ereg) gebruiken.

Verder kent ereg geen pattern delimiters (/ .. /) dus die moeten ook niet meegegeven worden.

[ Voor 60% gewijzigd door Soultaker op 25-07-2003 16:12 ]

[GraasGast]

bijna

PHP:

eregi("/^[a-z]*$/", $string)

dan dus...je gebruikt immers eregi

[simon]

Limhes schreef op 25 July 2003 @ 16:01:
[...]

PHP:

<?php
if (eregi("^[a-z]*$", $string))
{
    echo "Je string bevat <b>alleen</b> letters.."
}
?>

Want: eregi is van zichzelf al case-insensitive, jouw regexp was van het PCRE-type en hij wil alléén maar letters...

edit:
quote toegevoegd...

neem het mij niet kwalijk, ik copy-paste maar wat

Maar het is zoals Limhes zegt dus

[mbravenboer]

Als ik de verwarring zo bekijk is het wellicht een optie om mbv een for loopje even te itereren over de karakters .

[ACM]

GraasGast schreef op 25 July 2003 @ 16:06:
bijna

PHP:

eregi("/^[a-z]*$/", $string)

dan dus...je gebruikt immers eregi

Wat doen die / bij eregi?

Doe dan of met preg_match:
/^[a-z]*$/i

of met eregi:
^[a-z]*$

maar ga ze niet door elkaar gooien

[ Voor 20% gewijzigd door ACM op 25-07-2003 16:14 ]

[Soultaker]

mbravenboer schreef op 25 July 2003 @ 16:13:
Als ik de verwarring zo bekijk is het wellicht een optie om mbv een for loopje even te itereren over de karakters .

Ik ben geschockt! Jij zou van alle mensen op dit forum de declaratieve oplossing toch moeten weten waarderen!

[GraasGast]

ACM schreef op 25 July 2003 @ 16:13:
[...]

Wat doen die / bij eregi?

[...]

geen idee, ik gebruik nooit ereg, alleen pcre

[ Voor 60% gewijzigd door GraasGast op 25-07-2003 16:15 ]

[Kaastosti]

Mjah er is ook zoiets als is_string(), net als is_numeric(), maar ik weet niet of die string dan eventueel ook getallen mag bevatten. Anders wordt het inderdaad een eregi().

[ACM]

is_string bepaald alleen maar of het een variabele van type string is...

[D2k]

Soultaker schreef op 25 July 2003 @ 16:14:
[...]

Ik ben geschockt! Jij zou van alle mensen op dit forum de declaratieve oplossing toch moeten weten waarderen!

ik heb het idee dat ie een grapje maakt

_{anders zit er iemand anders onder zijn account te posten}

[mbravenboer]

Soultaker: Ik ben geschockt! Jij zou van alle mensen op dit forum de declaratieve oplossing toch moeten weten waarderen!

Het was idd grappig bedoeld (aardig overigens dat jullie denken dat het suggereren van een triviaal for loopje absoluut een grap moet zijn )

Helaas voor de oplossingen hier moet ik echter wel zeggen dit ik dit nog steeds aardiger vind:

code:

all(is-alpha)

of

code:

one(not(is-alpha))

of

code:

[a-zA-z]*

of

Haskell:

\s -> and (map isAlpha s)

Helaas is de regexp syntax ondertussen zo verpest dat het niet echt lollig is. Een nette syntax definitie taal heeft dan mijn sterke voorkeur.

[ACM]

mbravenboer schreef op 25 juli 2003 @ 16:57:
Helaas voor de oplossingen hier moet ik echter wel zeggen dit ik dit nog steeds aardiger vind:

code:

[a-zA-z]*

En waarin verschilt die regexp, behalve de syntax van een aanroep, met die in php ?

Ik vind met deze minimale regexpjes, het allemaal best meevallen. Tuurlijk is het leuker om het in-line, zoals met perl, te kunnen doen. Maar er valt nog altijd best mee te werken in php

[mbravenboer]

ACM: En waarin verschilt die regexp, behalve de syntax van een aanroep, met die in php ?

De zooi eromheen maar het het onduidelijkst ... Dat valt met name op bij de kleinste regexpen zoals deze triviale hier. Voor complexere regexpen is het voordeel van een goede syntax definitie taal overduidelijk. Dat heb ik al eens voor gedaan met een definitie van float literals ergens hier op GoT. Lang geleden .

[J3roen]

Waarom allemaal zo moeilijk met regex?

met de functie is_numeric($var) krijg je direct te zien of het een integer is of niet.

[ Voor 4% gewijzigd door J3roen op 25-07-2003 17:07 ]

[D2k]

CRiSiS schreef op 25 July 2003 @ 17:06:
Waarom allemaal zo moeilijk met regex?

met de functie is_numeric($var) krijg je direct te zien of het een integer is of niet.

waarom zou je een topic lezen he?

[ACM]

CRiSiS schreef op 25 July 2003 @ 17:06:
Waarom allemaal zo moeilijk met regex?

met de functie is_numeric($var) krijg je direct te zien of het een integer is of niet.

Omdat de TS wil dat het een ding van enkel letters is...

en trouwens, is_numeric accepteert ook 0.111 en 1,000,000.1 en 0.121e10 etc.... niet echt wat je een integer noemt...

[mbravenboer]

Dat sdf cool is liet ik trouwens zien in Het grote Regex field check topic . Het was meer een obfuscatie wedstrijd imho . Hier staat de code tegenwoordig: Java-Literals.sdf

[ Voor 5% gewijzigd door mbravenboer op 25-07-2003 17:15 ]

[mbravenboer]

Arien liet toen trouwens op Javahova zien dat Perl 6 niet onaardig is: Perl 6: Apocalypse 5

[Soultaker]

mbravenboer schreef op 25 July 2003 @ 16:57:
Het was idd grappig bedoeld (aardig overigens dat jullie denken dat het suggereren van een triviaal for loopje absoluut een grap moet zijn )

Uit jouw mond (/toetsenbord) wel, al was ik te geschokt om de grap in te zien.

Helaas voor de oplossingen hier moet ik echter wel zeggen dit ik dit nog steeds aardiger vind:
[..]

Ik zat ook al wat te klooien met hogere-orde functies. Ik kwam hier op uit:

PHP:

array_reduce(
    array_map(
        'ctype_alpha',
        preg_split('//', 'test', -1, PREG_SPLIT_NO_EMPTY)
    ),
    'and',
    1
);

Maar dat werkt niet omdat 'and' een operator is en geen functie en dan kan PHP 'm niet als callback gebruiken. Uiteraard is de lol er zo vanaf. Ook jammer dat je geen functiecompositie kunt toepassen, dan was iets als dit mogelijk geweest:

code:

empty(
    array_filter(
        preg_split('//', 'test', -1, PREG_SPLIT_NO_EMPTY), 
        not @ ctype_alphap
    )
)

Maar goed, PHP blijkt toch wat imperatief ingesteld te zijn.

Helaas is de regexp syntax ondertussen zo verpest dat het niet echt lollig is. Een nette syntax definitie taal heeft dan mijn sterke voorkeur.

Ik ben niet vies van een mooie regexp, al valt de herleesbaarheid soms wat tegen.

[mbravenboer]

Soultaker: Ik zat ook al wat te klooien met hogere-orde functies.

Wist niet dat je masochistische neigingen had . Was het nu maar een Python vraag he? .

[ACM]

Ik vind toch de regexp:

PHP:

if(preg_match('/^[a-z]+$/i', $input))
// of
if(eregi('^[a-z]+$', $input))

Toch echt duidelijker dan die constructies van jullie hoor

[D2k]

mbravenboer schreef op 25 July 2003 @ 17:17:
Arien liet toen trouwens op Javahova zien dat Perl 6 niet onaardig is: Perl 6: Apocalypse 5

offtopic:
Arien

[Soultaker]

mbravenboer schreef op 25 juli 2003 @ 17:32:
Wist niet dat je masochistische neigingen had . Was het nu maar een Python vraag he? .

Dat zou wel beter zijn, maar dan nog ondersteund Python geen functiecompositie of partial application (ik kan ook gedeeltelijke toepassing zeggen, maar dan begrijpt niemand me). Dat moet je dan maar emuleren met lamba definities...

(Al kent Python natuuwlijk wel '1 nivo' van partial application: "obj.method" is een closure die de overige argumenten van method ontvangt. Ik kan dus wel "map((1).__add__, [0,1,2,3]) doen!)

ACM schreef op 25 juli 2003 @ 17:40:
Ik vind toch de regexp:

PHP:

if(preg_match('/^[a-z]+$/i', $input))
// of
if(eregi('^[a-z]+$', $input))

Toch echt duidelijker dan die constructies van jullie hoor

Waarom zou je met "duidelijk" genoegen nemen, als je in plaats daarvan "mooi" kunt krijgen? Maar ik ben met je eens dat een goede reguliere expressie in dit geval veel mooier is...

[ Voor 51% gewijzigd door Soultaker op 25-07-2003 17:56 ]

[Verwijderd]

Soultaker schreef op 25 July 2003 @ 17:48:
Dat zou wel beter zijn, maar dan nog ondersteund Python geen functiecompositie of partial application (ik kan ook gedeeltelijke toepassing zeggen, maar dan begrijpt niemand me). Dat moet je dan maar emuleren met lamba definities...

Er zijn modules voor Python die dat wel ondersteunen zoals de xoltar-toolkit
/offtopic

[mbravenboer]

Soultaker: [partiele functie applicatie, functie composite]Dat moet je dan maar emuleren met lamba definities...

Ok, maar dat kan ook best aardig resultaten opleveren. Uiteraard is het nog steeds niet de meest ideale situatie wat functioneel programmeren betreft, maar je hebt tenminste wel wat aardige tools tot je beschikking.

[ACM]

mbravenboer schreef op 25 July 2003 @ 18:23:
Ok, maar dat kan ook best aardig resultaten opleveren. Uiteraard is het nog steeds niet de meest ideale situatie wat functioneel programmeren betreft, maar je hebt tenminste wel wat aardige tools tot je beschikking.

Ach, zolang Haskell e.a. naar C (of php for that matter) zijn te compileren zie ik niet in waarom er zo moeilijk gedaan moet worden met allerlei functionele talen/aanpakken e.d. terwijl zeker een voorbeeld als dit prima in php op te lossen is

En zeker omdat er '[PHP]' in de topictitel staat blijf ik daar in dit topic maar bij, hoewel de topicstarter niet echt meer van zich heeft laten horen.

[mbravenboer]

ACM: Ach, zolang Haskell e.a. naar C (of php for that matter) zijn te compileren zie ik niet in waarom er zo moeilijk gedaan moet worden met allerlei functionele talen/aanpakken

Je moet natuurlijk ook niet als doel hebben om in een niet functionele taal zoveel mogelijk functioneel te gaan programmeren, maar af en toe een map of een filter kunnen gebruiken is toch wel heel aardig.

Sowieso zou elke taal functies als expressies moeten toestaan (en liefst ook geneste functies). Als je nooit ff een functie kan meegeven aan een methode, is dat toch wel erg irritant moet ik zeggen ...

Overigens is dit topic inderdaad een wat onzinnige toepassing, maar ja ... .

[ACM]

mbravenboer schreef op 25 July 2003 @ 19:02:
Je moet natuurlijk ook niet als doel hebben om in een niet functionele taal zoveel mogelijk functioneel te gaan programmeren, maar af en toe een map of een filter kunnen gebruiken is toch wel heel aardig.

Ja, dat soort call-back zaken kunnen zeer nuttig zijn, vooral om functies lekker algemeen te houden

Sowieso zou elke taal functies als expressies moeten toestaan (en liefst ook geneste functies). Als je nooit ff een functie kan meegeven aan een methode, is dat toch wel erg irritant moet ik zeggen ...

Kan prima in php Hoewel geneste functies niet en daar zie ik het nut ook iets minder van in (owja, het was handig om bij de compilatie van haskell (of was het nou pascal) te gebruiken )

Overigens is dit topic inderdaad een wat onzinnige toepassing, maar ja ... .

Geeft niet
Zolang het maar enigszins interessant is.

[mbravenboer]

ACM: Hoewel geneste functies niet en daar zie ik het nut ook iets minder van in

Het gaat me niet zozeer om de geneste functie, maar om de lexicale scope (dat had ik er even bij moeten zeggen ... ). Geneste functies zonder lexicale scope hebben niet zoveel nut. Als je variabelen uit de omringende scope kan gebruiken, kan je zaken lekker compact opschrijven.

[stekkel]

ACM schreef op 25 July 2003 @ 19:10:

Kan prima in php Hoewel geneste functies niet en daar zie ik het nut ook iets minder van in (owja, het was handig om bij de compilatie van haskell (of was het nou pascal) te gebruiken )

geneste functies binnen PHP kunnen wel hoewel het niet echt toepasbaar is.

Wanneer je een geneste functie hebt dan kan je de functie waar het onderdeel van is slects 1 x aangeroepen worden anders wordt er een error gegenereerd.

Wel kan je in een if statement iets doen als:

PHP:

$s = '';
een($s);
echo $s;

function een(&$s) {
    $s .= 'geneste ';
    $s.= twee();
    if (!funcion_exist('twee')) {
        function twee() {
            return 'functie :) ';
        }
    }  
}

functie twee is dan een private function van een.

Het gaat zo wel erg off topic

[ Voor 26% gewijzigd door stekkel op 26-07-2003 00:45 ]

[Soultaker]

stekkel schreef op 25 July 2003 @ 23:40:
geneste functies binnen PHP kunnen wel hoewel het niet echt toepasbaar is.

Wanneer je een geneste functie hebt dan kan je de functie waar het onderdeel van is slects 1 x aangeroepen worden anders wordt er een error gegenereerd.

Maar ze zijn nogal nutteloos, omdat je er geen lexical scope bij krijgt. Dit werkt bijvoorbeeld niet:

PHP:

function outer()
{
    $text = 'world!';
    function inner()
    {
        return "Hello $text!";
    }
    return inner();
}

echo outer(); // print "Hello !" :(

Want die $text is gewoon lokaal voor inner. Tenzij er een scope modifier (zoals global) bestaat voor function scopes, kan inner dus nooit bij de variabelen van outer. Sterker nog, het is helemaal geen inner function, want dit werkt ook perfect:

PHP:

function outer()
{
    $text = 'world!';
    function inner()
    {
        return "Hello $text!";
    }
    return inner();
}

outer();
echo inner(); // print "Hello !" :(

Merk op dat de call naar outer nodig is om inner gedeclareerd te krijgen! Je uitspraak dat inner zo een private functie van outer is, vind ik dus wat teveel eer voor PHP: het is gewoon een globale functie die pas bij de evaluatie van outer() wordt gedeclareerd... Wat het hele idee is van deze constructie weet ik niet; ik kan me nauwelijks voorstellen dat 't nuttig is.

[ Voor 4% gewijzigd door Soultaker op 26-07-2003 01:05 ]

[Verwijderd]

Kant en klare functie: (volgensmij nog niet genoemd?)

ctype_alpha
(PHP 4 >= 4.0.4)

ctype_alpha -- Check for alphabetic character(s)
Description
bool ctype_alpha ( string text)


Returns TRUE if every character in text is a letter from the current locale, FALSE otherwise. In the standard C locale letters are just [A-Za-z] and ctype_alpha() is equivalent to (ctype_upper($text) || ctype_lower($text)), but other languages have letters that are considered neither upper nor lower case.

[bigtree]

Way to go Fuego! Deze functie(s) kende ik nog niet.

Om een nuttige bijdrage aan de draad te geven:

CTYPE functions are always prefered, when possible, to Regular Expressions and, often, even to some equivalent str_*, is_* functions. This is because of the fact that CTYPE uses a native C library and thus processes signitificaly faster.

(uit de comments van de manual)

[Verwijderd]

Ik ben er laatst ook pas achter gekomen, ze zijn vrij nieuw. Maar heel handig, ik gebruik ze nu al in vrijwel elk script.

De ctype_digit is erg handig voor het checken van id's (samen met > 0 dan),
ctype_alnum bijvoorbeeld voor gebruikersnamen, als je strlen er ook bij checkt voor de lengte die je wilt.

[Verwijderd]

Soultaker schreef op 26 juli 2003 @ 01:04:
Maar ze zijn nogal nutteloos, omdat je er geen lexical scope bij krijgt. Dit werkt bijvoorbeeld niet:

PHP:

function outer()
{
    $text = 'world!';
    function inner()
    {
        return "Hello $text!";
    }
    return inner();
}

$text als global definieren helpt een hoop (en is slordig), maar zo zou 't wel moeten werken (niet getest):

PHP:

function outer()
{
    function inner($arg)
    {
        return "Hello " . $arg . "!";
    }

    $text = 'world';
    return inner($text);
}

Ik gebruik een soortgelijke constructie (hier de addRow functie) op een LAMP systeempje:

PHP:

function getSystemInfo() {
    $cpuCmd = 'cat /proc/cpuinfo | awk  "BEGIN { cpu = \"\"; speed = 0 } ' .
                                        '\$0~/^model name/ { cpu = \$4 \" \" \$5 \" \" \$6 } ' .
                                        '\$0~/^cpu MHz/ { speed = \$4 } ' .
                                        'END {printf \"%s, %d MHz\", cpu, speed }"';

    $memCmd = 'cat /proc/meminfo | awk  "BEGIN { tot = 0; free = 0; cache = 0 } ' .
                                        '\$0~/^MemTotal:/ { tot = \$2/1024 } ' .
                                        '\$0~/^MemFree:/ { free += \$2/1024 } ' .
                                        '\$0~/^Cached:/ { cache = \$2/1024; free += cache } ' .
                                        'END {printf \"%d MB totaal, %d MB beschikbaar (incl. %d MB cache)\", ' .
                                                      'tot, free, cache }"';

    $diskspaceCmd = 'df | awk   "BEGIN { tot = 0; free = 0 } ' .
                                '\$1~/^\/dev\// { tot += \$2; free += \$4 } ' .
                                'END { printf \"%.1f GB totaal, %.1f GB beschikbaar\", ' .
                                               'tot/1048576, free/1048576 }"';

    function addRow($name, $value) {
        $row = "";
        if (($name > "") || ($value > "")) {
            $row =  "<tr>\n" .
                    "   <td width=\"12%\"><b>" . $name . "</b></td>\n" .
                    "   <td >" . $value . "</td>\n" .
                    "</tr>\n";
        }
        return $row;
    }

    $result = "<table class='uptime' cellpadding='0' cellspacing='2' border='0' width='90%' align='center'>\n";
    $result .=  addRow("Server",        exec('echo $HOSTNAME') . ", " . exec('uname -sr'));
    $result .=  addRow("Uptime",        exec('uptime'));
    $result .=  addRow("Processor",     exec($cpuCmd));
    $result .=  addRow("Geheugen",      exec($memCmd));
    $result .=  addRow("Schijfruimte",  exec($diskspaceCmd));
    $result .=  "</table>\n";
    return $result;
}

...en dat werkt prima.

Maar 't heeft idd niks met lexical scope te maken, en het feit dat je die inner() functie globaal kunt maken door eerst outer() aan te roepen is m.i. een grote flaw in PHP. Daardoor heb je bv. ook geen "echte" private/protected variabelen binnen PHP-objecten.

[ACM]

Waarom zou je die addRow niet gewoon buiten die functie definieren? Aangezien die scope toch niet goed werkt (en dat nou juist een aardige feature van innerfunctions is), kan je dat net zo goed doen.

Verder denk ik dat de "inner"-functie-declaratie niet te vergelijken is met de private/protected members van PHP-objecten

[Verwijderd]

ACM schreef op 26 July 2003 @ 16:30:
Waarom zou je die addRow niet gewoon buiten die functie definieren?

Daar hoort 'ie niet. 't Is een onderdeel van getSystemInfo, dus daar moet 'ie ook staan. Ik weet wel dat PHP daar niet zo jofel me omgaat, maar ja, ik ben en blijf Delphi progger...

Verder denk ik dat de "inner"-functie-declaratie niet te vergelijken is met de private/protected members van PHP-objecten

Oorzaak is hetzelfde, denk ik. PHP kent geen gelaagde afscherming van buitenaf, waardoor je in feite overal bij kan.

[ACM]

Verwijderd schreef op 27 July 2003 @ 12:51:
Daar hoort 'ie niet. 't Is een onderdeel van getSystemInfo, dus daar moet 'ie ook staan. Ik weet wel dat PHP daar niet zo jofel me omgaat, maar ja, ik ben en blijf Delphi progger...

Dat snap ik niet. Waarom zou de functie-declaratie nou weer binnen die getSystemInfo horen
Als je een taal had die dat soort declaraties niet zou toestaan, zou je de functie maar gewoon weglaten ofzo Want hij hoort niet ergens anders...

Imho kan je elke functie die je nodig hebt prima buiten alle andere declareren, sterker nog, dat is ook wel een beetje de bedoeling meestal van de syntax.

Oorzaak is hetzelfde, denk ik. PHP kent geen gelaagde afscherming van buitenaf, waardoor je in feite overal bij kan.

Ik denk zelf dat de functie-declaratie al op een veel lager niveau geregeld wordt, iig de declaratie-"header" oid. Afscherming van onderdelen is weer heel wat anders, eigenlijk zou de functie-header een scope moeten hebben om dit allemaal correct af te handelen.
Maar het zichtbaar/onzichtbaar zijn van object-parameters heeft weinig met scopes te maken

[bigtree]

@ Afterlife & ACM... zouden we hier niet beter een ander topic voor openen? Zijn nu ook de vakantie-mods met vakantie of zo?

[Rense Klinkenberg]

Verwijderd schreef op 26 July 2003 @ 13:47:
...
Maar 't heeft idd niks met lexical scope te maken, en het feit dat je die inner() functie globaal kunt maken door eerst outer() aan te roepen is m.i. een grote flaw in PHP....

PHP beschouwt het ook niet als geneste functies, maar als een conditionele functie. Kijk maar eens naar http://nl2.php.net/functions#AEN5456. Daar wordt het ook vergeleken met:

PHP:

<?php
$makefoo = true;

/* We can't call foo() from here 
   since it doesn't exist yet,
   but we can call bar() */

bar();

if ($makefoo) {
  function foo ()
  {
    echo "I don't exist until program execution reaches me.\n";
  }
}

/* Now we can safely call foo()
   since $makefoo evaluated to true */

if ($makefoo) foo();

function bar() 
{
  echo "I exist immediately upon program start.\n";
}

?>

[Soultaker]

Verwijderd schreef op 26 juli 2003 @ 10:55:
Kant en klare functie: (volgensmij nog niet genoemd?)

Ik gebruikte 'm al in voorbeeldcode, om op enkele karakters te testen, maar inderdaad, je kan 'm net zo goed voor de hele string gebruiken.

Verwijderd schreef op 26 July 2003 @ 13:47:
$text als global definieren helpt een hoop (en is slordig), maar zo zou 't wel moeten werken (niet getest):

Behalve dat je code nergens globals gebruikt, vind ik dit niet "werken". Dan heb je nog steeds losse functies die allemaal globale variabelen gebruiken; dat lost dus helemaal niets op! (Ik vind het ook niet "een hoop" helpen.) Het hele idee van een geneste functie was dat je toegang hebt tot de lokale scope van de functie waarin 'ie genest wordt.

Ik gebruik een soortgelijke constructie (hier de addRow functie) op een LAMP systeempje:
[..]
...en dat werkt prima.

Dat werkt toch helemaal niet? Je kunt nu je buitenste functie maar éénmaal aanroepen anders breekt PHP af, je kunt je binnenste functie nu van buiten gebruiken, wat niet de bedoeling is, en als je elders een functie met dezelfde naam als je binnenste functie gebruikt, breekt PHP ook af als je je buitenste functie aanroept.

Met de nesting suggereer je dat het vielig is om een veelgebruikte functienaam als "addRow" te definiëren, maar dat is dus niet zo. Je code is net zo "goed" als wanneer je die "addRow" buiten je functie had gedefinieerd. Je suggereert dat het goed gaat als je twee functies hebt die allebei een andere functie "addRow" definiëren, maar dat is niet zo. Je communiceert dus een bepaalde betekenis door de opmaak van je coed, die de code volgens PHP gewoon niet heeft!

Stellen dat die oplossing prima werkt, vind ik dus schromelijk overdreven. Het kan in jouw simpele scriptje, waar er maar één functie is die deze truc uithaalt, en waarin die functie nota bene hooguit één keer kan worden aangeroepen (waar heb je dan nog functies voor?), wel werken, maar daar houdt 't wat mij betreft mee op. Je code zou een stuk beter zijn als je die "addRow" helder buiten de functie getSystemInfo zou plaatsen en zou hernoemen naar iets als "getSystemInfo_addRow" of iets dergelijks, om clashes met andere functienamen te voorkomen.

[Verwijderd]

Soultaker schreef op 27 juli 2003 @ 18:03:Je code zou een stuk beter zijn als je die "addRow" helder buiten de functie getSystemInfo zou plaatsen en zou hernoemen naar iets als "getSystemInfo_addRow" of iets dergelijks, om clashes met andere functienamen te voorkomen.

Je hebt 100% gelijk, en ik heb blijkbaar nog een hoop te leren m.b.t. de mogelijkheden en beperkingen van PHP...