[PHP] andere manier van parse/efficientie?

zondag 25 mei 2003 23:11

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Hey,

Ik vroeg me nu toch iets af. Ik schrijf php zoals ik C++ schrijf. Dus mijn mijn heel php bestand beschouw ik als code en als ik iets wil outputten naar het scherm doe ik dat als volgt:

code:

<?
$naam = "jaap";

// ...beetje code hier...

echo "
<html>
 <head>
 </head>
 <body>
   hello $naam<br>";

$naam = "dirk";

echo "
    dag $naam<br>
 </body>
</hmtl>";

...nog een beetje code hier...

?>

Nu in iedere PHP manual doen ze het anders natuurlijk en wel als volgt:

code:

<html>
 <head>
 </head>
 <body>
   hello <? echo $naam; ?><br>
<? $naam = "dirk";?>
   dag  <? echo $naam ?><br>
 </body>
</hmtl>

Beide doen het even goed. Maar toch vraag ik me af waarom iedereen het zo doet. Heeft het te maken met efficientie van het parsen? Nochtans, mijn parse tijden zijn in de orde van 100ms. Wat mij perfect normaal lijkt. Vraag me niet waarom ik het anders doe. Ik heb altijd al zo geprogrammeerd en ik vind dat mijn code dan perfect leesbaar blijft. Kwestie van gewente ook. Zijn er nog mensen die zoals mij PHP code schrijven???

Joep,
FraG

zondag 25 mei 2003 23:15

Acties:

0 Henk 'm!

Grijze Vos

Dat komt omdat php van oudsher als script-taal een soort 'add-on' is voor HTML. Vroeger had je een hele zooi HTML, met een beetje PHP om wat database-gedoe te doen.

Tegenwoordig heb je meestal veel PHP, en is die HTML alleen maar een schil. Het is naar mijn bescheiden mening een stuk mooier om het op die eerste manier te doen. Daarmee zorg je namelijk dat de HTML lost staat van je code,en is het geheel overzichtelijker. Bovendien kun je digen als die HTML header en footer in verschillende files te stoppen, en zo je totaal aantal code flink te verkleinen.

Sorry als mijn verhaal een beetje warrig klinkt,maarmijn hoofdpijn zorgt dat ik niet 100%goedkan nadenken.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zondag 25 mei 2003 23:20

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

in principe zou het in en uit PHP mode springen een iets lagere performance moeten hebben, maar in de praktijk blijkt dit nauwelijks meetbaar.
Wat je wel in performance merkt is het verschil tussen:

PHP:

1	echo "Dit is een var: $somevar";

en

PHP:

1	echo 'Dit is een var: '.$somevar;

de 2e is zo'n 50% sneller, en in een editor met syntax-highlighting ook nog eens leesbaarder (en dus onderhoudbaarder).
Bij lange lappen HTML en relatief weinig PHP variabelen die ge-output moeten worden spring ik vaak uit PHP mode en gebruik ik hier en daar <?php echo $somevar; ?>
Als de hoeveelheid PHP code toeneemt, dan wil ik nog wel eens langere strings HTML echo-en, maar altijd met variabelen geconcat.

Intentionally left blank

zondag 25 mei 2003 23:22

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Neuh hoor, ik kan wel volgen. Maar ik stop hoofd, menu, ... ook in aparte bestanden hoor. include ("top.php");
include ("menu.php");
enz enz...

Tja, en het blijft een kwestie van gewente en eigen keuze. Maar ik vroeg me nu toch wel af of de ene efficienter is dan de andere. Waarschijnlijk zal het verschil zo miniem zijn.

zondag 25 mei 2003 23:23

Acties:

0 Henk 'm!

Bosmonster

*zucht*

En methode 2 heeft ook voordelen voor syntax highlighting en wysiwig editors (ik niet, maar sommige collega's gebruiken ze wel

). Zo zie je tenminste nog iets in je editor.

Bovendien voert PHP alleen die delen uit tussen php-tags.. dus waarom alles waar niks mee hoeft te gebeuren in PHP-tags stoppen? Zonde van de performance. En bij een flinke load een gehele html pagina echo'en voor iedere user gaat je flink wat geheugen kosten

[ Voor 44% gewijzigd door Bosmonster op 25-05-2003 23:24 ]

maandag 26 mei 2003 01:16

Acties:

0 Henk 'm!

Verwijderd

Bosmonster schreef op 25 mei 2003 @ 23:23:
En methode 2 heeft ook voordelen voor syntax highlighting en wysiwig editors (ik niet, maar sommige collega's gebruiken ze wel ). [knip]

Ik gebruik PHPEdit, ik zie een string ook staan binnen de code op de 1e manier. Dan wordt hij nog opvallender, hij wordt zelfs bold. Dus het is maar hoe je edit

maandag 26 mei 2003 01:33

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

ik vind het automatisch-parsen-van-variabelen-binnen-strings-omgeven-door-dubbele-quotes eigenlijk nogal ranzig, en vrij van bugs is het ook niet:

PHP:

1 2	$eenarray = array('foo' => 'bar'); echo "een array element: $eenarray['foo']";

gaat dus fout...

Intentionally left blank

maandag 26 mei 2003 01:37

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

crisp schreef op 25 May 2003 @ 23:20:
in principe zou het in en uit PHP mode springen een iets lagere performance moeten hebben, maar in de praktijk blijkt dit nauwelijks meetbaar.

Ik heb wel eens gelezen dat dat helemaal niet uitmaakt, aangezien het intern exact hetzelfde werkt. Dat string uitspugen of 'uit php springen'...

Wat je wel in performance merkt is het verschil tussen:
PHP:
1
echo "Dit is een var: $somevar";
en
PHP:
1
echo 'Dit is een var: '.$somevar;
de 2e is zo'n 50% sneller, en in een editor met syntax-highlighting ook nog eens leesbaarder (en dus onderhoudbaarder).

Merk je dat echt

Wow... jij hebt een goed tijdsgevoel dan

Het verschil is overigens weer kleiner als je:
echo "Dit is een var: {$somevar}"; neemt en die wordt in een aantal editors _nog_ mooier gehighlight.

Als de hoeveelheid PHP code toeneemt, dan wil ik nog wel eens langere strings HTML echo-en, maar altijd met variabelen geconcat.

Ik gebruik juist vaak die {}-methode, tenzij ik een functie ergens tussenin aanroep.

Imho moet je de keus voor quotes niet laten afhangen van de performance, die is met recente php-versies nagenoeg gelijk en sowieso al vrij goed.

De ' is handig als je zeker wilt weten dat er geen rare dingen geparsed worden, de " is weer handiger als je veel ' intern gebruikt (Sql-strings bijvoorbeeld) of parameters in wilt kunnen voegen, etc.

maandag 26 mei 2003 01:45

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

ACM schreef op 26 May 2003 @ 01:37:
[...]

Merk je dat echt
Wow... jij hebt een goed tijdsgevoel dan

wel als je het 100000 keer in een loop doet

Het verschil is overigens weer kleiner als je:
echo "Dit is een var: {$somevar}"; neemt en die wordt in een aantal editors _nog_ mooier gehighlight.
[...]
Ik gebruik juist vaak die {}-methode, tenzij ik een functie ergens tussenin aanroep.

da's bijna net zoveel extra typwerk als '. .'

(voor { } moet je shift nog induwen)

Imho moet je de keus voor quotes niet laten afhangen van de performance, die is met recente php-versies nagenoeg gelijk en sowieso al vrij goed.

De ' is handig als je zeker wilt weten dat er geen rare dingen geparsed worden, de " is weer handiger als je veel ' intern gebruikt (Sql-strings bijvoorbeeld) of parameters in wilt kunnen voegen, etc.

ik ken geen enkele andere taal die dit soort functionaliteit heeft (kan aan mijn beperkte talen-kennis liggen), dus ik ben niets anders gewend dan de boel te moeten concatten. imho werken dit soort dingen juist fouten in de hand, vandaag weer een gevalletje gehad met een code highlight functie:

PHP:

1	$content = preg_replace('/\\[code\](.*?)\\[\/code\]/ise', 'highlighting("$1")', $content);

goh, waar komen die notices toch vandaan?

oh ja, dit vind ik dus echt ueberranzig:

PHP:

1	echo "<input type=\"text\" name=\"naam\" value=\"crisp\" />";

maar dit ook:

PHP:

1	echo "<input type='text' name='naam' value='crisp' />";

er is namelijk een reden waarom attributen in html het beste met een dubbele quote omgeven kunnen worden: namelijk het feit dat een dubbele quote een entitie (") heeft en een enkele quote niet...

PHP:

1	echo '<input type="text" name="naam" value="iets tussen "dubbele quotes"" />';

[ Voor 31% gewijzigd door crisp op 26-05-2003 02:00 ]

Intentionally left blank

maandag 26 mei 2003 02:24

Acties:

0 Henk 'm!

Grijze Vos

maar in je laatste voorbeeld, crisp, kun je weer niet variabelen erin zetten, en ben je verplicht te concatten

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

maandag 26 mei 2003 02:41

Acties:

0 Henk 'm!

Helox-in-a-box

huh?

crisp schreef op 25 mei 2003 @ 23:20:
Wat je wel in performance merkt is het verschil tussen:
PHP:
1
echo "Dit is een var: $somevar";
en
PHP:
1
echo 'Dit is een var: '.$somevar;
de 2e is zo'n 50% sneller, en in een editor met syntax-highlighting ook nog eens leesbaarder (en dus onderhoudbaarder).

kheb het ff getest met een loop van 10.000 en er is zeker geen meetbaar verschil tussen de 2 'types' code.

getest met dit stukje code:

PHP:

function getmicrotime(){
    list($usec, $sec) = explode(" ",microtime());
    return ((float)$usec + (float)$sec);
}

$tijd = getmicrotime();

for ($i = 0; $i < 10000; $i++) {
    echo 'Dit is een var: '.$somevar;
                // echo "Dit is een var: $somevar";
}

$tijd = getmicrotime() - $tijd;
echo "<br>".$tijd;

en dit zijn de tijden die bij mij eruit kwamen:
echo "Dit is een var: $somevar";
1.6401590108871
1.2987409830093
1.2814749479294
1.2912349700928
1.3915120363235

echo 'Dit is een var: '.$somevar;
1.5643390417099
1.5476649999619
1.3033839464188
1.3631380796432
1.5627189874649

zoals je ziet bijna geen verschil.

maandag 26 mei 2003 07:37

Acties:

0 Henk 'm!

Onno

crisp schreef op 26 mei 2003 @ 01:45:
imho werken dit soort dingen juist fouten in de hand, vandaag weer een gevalletje gehad met een code highlight functie:
PHP:
1
$content = preg_replace('/\\[code\](.*?)\\[\/code\]/ise', 'highlighting("$1")', $content);
goh, waar komen die notices toch vandaan?

Maar /e is dan ook een slecht/onhandig geimplementeerde perl-constructie. In perl werkt /e goed, in php kun je beter preg_replace_callback gebruiken.

maandag 26 mei 2003 08:52

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

Onno schreef op 26 May 2003 @ 07:37:
[...]

Maar /e is dan ook een slecht/onhandig geimplementeerde perl-constructie. In perl werkt /e goed, in php kun je beter preg_replace_callback gebruiken.

In dit geval werkt de preg_replace prima, alleen de $1 wordt nog even geparsed doordat 'ie tussen dubbele quotes staat. Dit werkt dus naar behoren:

PHP:

1	$content = preg_replace('/\\[code\](.*?)\\[\/code\]/ise', 'highlighting(\'$1\')', $content);

Helox-in-a-box schreef op 26 May 2003 @ 02:41:
[...]
kheb het ff getest met een loop van 10.000 en er is zeker geen meetbaar verschil tussen de 2 'types' code.

[...]

zoals je ziet bijna geen verschil.

Hij is bij jou druk bezig notices af te vangen omdat $somevar niet gedefinieerd is

PHP:

<?php

function getmicrotime(){ 
    list($usec, $sec) = explode(" ",microtime()); 
    return ((float)$usec + (float)$sec); 
} 

$tijd = getmicrotime(); 
$somevar = 'bla';

for ($i = 0; $i < 10000000; $i++) { 
     $anothervar = 'Dit is een var: '.$somevar; 
  // $anothervar = "Dit is een var: $somevar"; 
} 

$tijd = getmicrotime() - $tijd; 
echo $tijd;

?>

$anothervar = 'Dit is een var: '.$somevar; - 11.81 sec
$anothervar = "Dit is een var: $somevar"; - 23.57 sec

win2k, PHP 4.3.1 onder IIS5 (CGI-mode), AMD XP2000+

Grijze Vos schreef op 26 May 2003 @ 02:24:
maar in je laatste voorbeeld, crisp, kun je weer niet variabelen erin zetten, en ben je verplicht te concatten

Daar is dus niets mis mee

[ Voor 13% gewijzigd door crisp op 26-05-2003 08:55 ]

Intentionally left blank

maandag 26 mei 2003 09:07

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

$anothervar = 'Dit is een var: '.$somevar; - 11.81 sec
$anothervar = "Dit is een var: $somevar"; - 23.57 sec

Interesting

Nog zo van die leuke performantie dingetjes? Ik ga me ook eens zo loop ding schrijven voor een en ander te testen.

maandag 26 mei 2003 10:16

Acties:

0 Henk 'm!

Onno

crisp schreef op 26 mei 2003 @ 08:52:
In dit geval werkt de preg_replace prima, alleen de $1 wordt nog even geparsed doordat 'ie tussen dubbele quotes staat. Dit werkt dus naar behoren:
PHP:
1
$content = preg_replace('/\\[code\](.*?)\\[\/code\]/ise', 'highlighting(\'$1\')', $content);

Prima?

PHP:

function test ($bla)
{
  return $bla;
}

$x = "bla'bl()a'bl\"aaa'piep\n";

print $x;
print preg_replace('/(.*)/e', 'test(\'$1\')', $x);
print preg_replace('/(.*)/e', 'test("$1")', $x);

Uitvoer:

code:

1
2
3

bla'bl()a'bl"aaa'piep
bla'bl()a'bl\"aaa'piep
bla\'bl()a\'bl"aaa\'piep

Het probleem met /e in PHP is dat $1, enz. geen echte variabelen zijn zoals in perl. Dus probeert PHP ze maar 'slim' te expanden. En dat gaat vroeg of laat fout.

[ Voor 15% gewijzigd door Onno op 26-05-2003 10:17 ]

maandag 26 mei 2003 11:19

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

Onno schreef op 26 May 2003 @ 10:16:
[...]

Prima?
[...]
Het probleem met /e in PHP is dat $1, enz. geen echte variabelen zijn zoals in perl. Dus probeert PHP ze maar 'slim' te expanden. En dat gaat vroeg of laat fout.

Ik heb het idee dat php er nog een addslashes overheen haalt alvorens het resultaat te evalueren, je krijgt dan dus repectievelijk:

eval(test('bla\'bl()a\'bl\"aaa\'piep\n'));
eval(test("bla\'bl()a\'bl\"aaa\'piep\n"));

het resultaat laat zich dan raden ja; gek dat me dat nooit eerder opgevallen is...
Er is natuurlijk wel omheen te werken als je dit eenmaal weet.

[ Voor 17% gewijzigd door crisp op 26-05-2003 11:20 ]

Intentionally left blank

maandag 26 mei 2003 13:39

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

Php gooit er een vorm van addslashes overheen over de quotes die je 'eromheen' gebruikt oid. Erg onhandig.

Btw:
15s voor de ''
26s voor de tweede.

En ja, dat is 10 seconden verschil, op 10000000 string operaties dus per operatie is dat dus zo'n 0,000001 per iteratie...

Denk dat je beter je tijd van het optimisen ergens anders aan kan besteden, een query die een ms sneller uitgevoerd kan worden win je dus al 1000 stringconcats mee.
Tenzij je natuurlijk extreem veel strings uitspuugt...

[ Voor 5% gewijzigd door ACM op 26-05-2003 13:40 ]

maandag 26 mei 2003 13:49

Acties:

0 Henk 'm!

Onno

crisp schreef op 26 May 2003 @ 11:19:
Er is natuurlijk wel omheen te werken als je dit eenmaal weet.

Niet netjes, tenzij je functies wilt gaan schrijven waaraan je meegeeft wat voor soort quotes er gebruikt is tijdens de aanroep ofzo. (je kunt alleen aan de waarde immers niet zien of je de slashes voor double of voor single quotes moet wegdenken)
En aangezien dat wel zo enorm lelijk is, kun je beter de wat elegantere oplossing die preg_replace_callback biedt gebruiken.

dinsdag 27 mei 2003 00:28

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

ACM schreef op 26 May 2003 @ 13:39:
Php gooit er een vorm van addslashes overheen over de quotes die je 'eromheen' gebruikt oid. Erg onhandig.

Btw:
15s voor de ''
26s voor de tweede.

En ja, dat is 10 seconden verschil, op 10000000 string operaties dus per operatie is dat dus zo'n 0,000001 per iteratie...

Denk dat je beter je tijd van het optimisen ergens anders aan kan besteden, een query die een ms sneller uitgevoerd kan worden win je dus al 1000 stringconcats mee.
Tenzij je natuurlijk extreem veel strings uitspuugt...

tuurlijk, een normaal script heeft geen 10.000.000 string operaties, dus het is maar een klein argument. Toch vind ik het coden met enkele quotes om strings, en het gebruik van concat voor variabelen gewoon handiger voornamelijk vanwege de leesbaarheid, en het feit dat ik gewoon HTML strings met attributen tussen dubbele quotes kan echo-en zonder te hoeven escapen.

Onno schreef op 26 May 2003 @ 13:49:
[...]

Niet netjes, tenzij je functies wilt gaan schrijven waaraan je meegeeft wat voor soort quotes er gebruikt is tijdens de aanroep ofzo. (je kunt alleen aan de waarde immers niet zien of je de slashes voor double of voor single quotes moet wegdenken)
En aangezien dat wel zo enorm lelijk is, kun je beter de wat elegantere oplossing die preg_replace_callback biedt gebruiken.

is inderdaad niet netjes omdat het een "workaround" is, de callback is dan inderdaad een betere oplossing

Intentionally left blank

dinsdag 27 mei 2003 07:33

Acties:

0 Henk 'm!

Verwijderd

Ik heb ooit eens gelezen dat het concatineren met komma's ipv punten nog sneller zou moeten zijn:

PHP:

1	echo 'Dit is een var: '.$somevar;

0.072228074073792
0.056252002716064
0.052262067794823
0.057539105415344
0.050812005996704

PHP:

1	echo 'Dit is een var: ', $somevar;

0.064913034439087
0.053126931190491
0.051211953163147
0.052675008773804
0.050129055976868

Na testen: onzin dus.

dinsdag 27 mei 2003 11:58

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

Verwijderd schreef op 27 mei 2003 @ 07:33:
Ik heb ooit eens gelezen dat het concatineren met komma's ipv punten nog sneller zou moeten zijn:

Dat is geen concatenatie... echo kan gewoon meerdere input vars lezen en het is wel iets sneller, maar niet veel.

donderdag 31 juli 2003 16:52

Acties:

0 Henk 'm!

Tjeerd

Be Original, Be Yourself.

Ik weet niet of het hier direct in dit topic past, maar het laatste stukje gaat over preg en functies gebruik, waar ik een probleem mee heb.
Ik heb een klasse:

PHP:

class parser_bb
{
 var $text;

  function codeparse($code)
   {
    ob_start();
    $code = ob_get_contents();
    ob_end_clean();
    return $code;
   }

  function parse()
  {
   $string = $this->text;
  
   $htmlstring =  preg_replace("/\\[code\](.+?)\\[\/code]", $this->codeparse(\\'$1\'),$htmlstring);

   return $htmlstring;
  }
}

Dat is globaal de klasse, maar het probleem zit hem in het aanroepen van die functie. Ik heb echt tig verschillende mogelijkheden geprobeerd:
- \\1 gebruiken
- tussen enkele of dubbele quotes

En maar niet willen werken, help, hoe in vredesnaam moet ik die functie aanroepen in de preg_replace functie? Al veel topics zitten zoeken, maar kon alleen maar voorbeelden vinden waarin geen functie binnen dezelfde klasse werd aangeroepen als parameter bij preg_replace. En ik denk dat daar het probleem zit, maar waar?

Om een of andere reden valt bij de code hierboven bij de functie aanroep de \' weg bij het argument, dat moeten allebei \' zijn.

[ Voor 25% gewijzigd door Tjeerd op 31-07-2003 16:56 ]

www.tjeerd.net - To repeat what others have said, requires education, to challenge it, requires brains.

donderdag 31 juli 2003 17:15

Acties:

0 Henk 'm!

Grijze Vos

crisp, ik heb nog een leuke voor je.

echo 'bla\n';
en
echo "bla\n";

De eerste zorgt niet voor een newline, de tweede wel. Of ligt dat aan mij?

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

donderdag 31 juli 2003 17:30

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

Nestor schreef op 31 juli 2003 @ 16:52:
Ik weet niet of het hier direct in dit topic past, maar het laatste stukje gaat over preg en functies gebruik, waar ik een probleem mee heb.
Ik heb een klasse:

[...]
Dat is globaal de klasse, maar het probleem zit hem in het aanroepen van die functie. Ik heb echt tig verschillende mogelijkheden geprobeerd:
- \\1 gebruiken
- tussen enkele of dubbele quotes
[...]

ik kan er naast zitten, maar ik dacht zo:

PHP:

1	$htmlstring = preg_replace('/\\[code\](.+?)\\[\/code\]/e', '\$this->codeparse(\'$1\')',$htmlstring);

maar wellicht krijg je scope-problemen; preg_replace_callback kan ook nog een optie zijn (soms zelfs beter).

Grijze Vos schreef op 31 juli 2003 @ 17:15:
crisp, ik heb nog een leuke voor je.

echo 'bla\n';
en
echo "bla\n";

De eerste zorgt niet voor een newline, de tweede wel. Of ligt dat aan mij?

logisch; bij de 1e wordt de string letterlijk genomen, bij de 2e wordt de \n geinterpreteerd naar een linebreak

Intentionally left blank

donderdag 31 juli 2003 17:37

Acties:

0 Henk 'm!

beetle71

Nestor schreef op 31 juli 2003 @ 16:52:
Ik weet niet of het hier direct in dit topic past, maar het laatste stukje gaat over preg en functies gebruik, waar ik een probleem mee heb.
Ik heb een klasse:

PHP:

1	$htmlstring = preg_replace('/\\[code\](.+?)\\[\/code\]/e', "$this->codeparse('\\1')",$htmlstring);

zie ook deze reply in een ander topic

offtopic:
Over fouten door code highlighting gesproken... de code highlighting van GOT is in bovenstaande code ook niet helemaal jofel

donderdag 31 juli 2003 19:02

Acties:

0 Henk 'm!

Grijze Vos

logisch; bij de 1e wordt de string letterlijk genomen, bij de 2e wordt de \n geinterpreteerd naar een linebreak

Daarom gebruik ik dus liever " " ipv ' '.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

donderdag 31 juli 2003 19:04

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

Grijze Vos schreef op 31 July 2003 @ 19:02:
[...]
Daarom gebruik ik dus liever " " ipv ' '.

En ik dus juist niet

PHP:

1
2
3

define ('CR', "\n");

echo 'bla'.CR;

Intentionally left blank

donderdag 31 juli 2003 19:40

Acties:

0 Henk 'm!

Grijze Vos

Hmz, ziet er leuk uit

* Grijze Vos voelt een grote replace actie aankomen

Maarre, die constante, is die in elke functie gedefinieerd? Ik gok van niet. En dat lijkt me irri.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

donderdag 31 juli 2003 20:41

Acties:

0 Henk 'm!

cybermans

Als we helemaal op de miereneuk toer gaan weet ik er ook nog een. Is ooit al een hele discussie over geweest.
het verschil tussen <? en <?PHP. De laatste is het best te gebruiken omdat bv xml start met <?xml .... en als je dan short tags aan hebt staan kan dat misgaan. Weet niet of dit nog iets uit maakt met snelheid.

Strava | Runkeeper | Endomondo (mijn leikr uploads)

donderdag 31 juli 2003 22:50

Acties:

0 Henk 'm!

bigtree

Grijze Vos schreef op 31 July 2003 @ 19:40:
Maarre, die constante, is die in elke functie gedefinieerd? Ik gok van niet. En dat lijkt me irri.

Yep:

PHP:

define (CR, "\n");

function foo() {
    return "x" . CR . "x";
}  

echo nl2br(foo());

levert:

code:

1
2

x
x

Lekker woordenboek, als je niet eens weet dat vandalen met een 'n' is.

donderdag 31 juli 2003 23:56

Acties:

0 Henk 'm!

Grijze Vos

handig

* Grijze Vos gaat binnenkort maar es code opschonen dan.

Alhoewel ik sowieso eraan denk om mn echo's door pirntf-jes te vervangen...

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

Onderwerpen