Re: PHP $ --> ?

[Maarten Wierda]

Sander wrote:

[f'up -> nl.internet.www.server-side]

> MAAR.... bij test1.php
> <?
> echo "hallo mijn naam is $naam";
> ?>
>
> als ik nu
> http://localhost/test1.php?naam=mitchell
>
> intype
> zou mijn naam ingevuld moeten worden...toch?
>
> Weet iemand wat het probleem is?

Ja. Je moet superglobals gebruiken, dus in dit geval:

<?php

echo "hallo mijn naam is ".$_GET["naam"]."";

?>

... omdat het een GET-var betreft. Leer jezelf trouwens af variabelen
tussen quotes te gebruiken.

Succes.


--
Cheers, Maarten Wierda
cp: Julie Ruin - Aerobicide

"Smack it! Beat it! Masturbate it!" - K.D. Cobain

[Daniel Tryba]

In nl.internet.www.server-side Maarten Wierda <moart3nAT@norecessdot.com> wrote:
> <?php
>
> echo "hallo mijn naam is ".$_GET["naam"]."";
>
> ?>
>
> .. omdat het een GET-var betreft. Leer jezelf trouwens af variabelen
> tussen quotes te gebruiken.

Vanwaar dit vaag advies? Zeker gezien jou gebruik van " is dit zeer
verbazing wekkend.

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

> > <?php
> >
> > echo "hallo mijn naam is ".$_GET["naam"]."";
> >
> > ?>
> >
> > .. omdat het een GET-var betreft. Leer jezelf trouwens af variabelen
> > tussen quotes te gebruiken.
>
> Vanwaar dit vaag advies? Zeker gezien jou gebruik van " is dit zeer
> verbazing wekkend.

*schaam* Best slordig voorbeeld idd. En ik lees doorgaans dat variabelen
tussen quotes af te raden is.

Zie bijv. <http://www.yapf.net/faq.php?cmd=viewitem&itemid=605>

--
Cheers, Maarten Wierda

"Won't you believe it. It's just my luck. No Recess." - K.D. Cobain

[ikÿ]

> > > .. omdat het een GET-var betreft. Leer jezelf trouwens af variabelen
> > > tussen quotes te gebruiken.
> >
> > Vanwaar dit vaag advies? Zeker gezien jou gebruik van " is dit zeer
> > verbazing wekkend.
>
> *schaam* Best slordig voorbeeld idd. En ik lees doorgaans dat variabelen
> tussen quotes af te raden is.
>
> Zie bijv. <http://www.yapf.net/faq.php?cmd=viewitem&itemid=605>

Gaat er alleen maar om dat je single-quotes gebruikt, dan wordt het een
literal (dus hoeft php niet te gaan kijken of er iets met de naam moet
gebeuren). Kwestie van snelheid en bug preventie

[Maarten Wierda]

"ikÿ" wrote:

> > > > .. omdat het een GET-var betreft. Leer jezelf trouwens af variabelen
> > > > tussen quotes te gebruiken.
> > >
> > > Vanwaar dit vaag advies? Zeker gezien jou gebruik van " is dit zeer
> > > verbazing wekkend.
> >
> > *schaam* Best slordig voorbeeld idd. En ik lees doorgaans dat variabelen
> > tussen quotes af te raden is.
> >
> > Zie bijv. <http://www.yapf.net/faq.php?cmd=viewitem&itemid=605>
>
> Gaat er alleen maar om dat je single-quotes gebruikt, dan wordt het een
> literal (dus hoeft php niet te gaan kijken of er iets met de naam moet
> gebeuren). Kwestie van snelheid en bug preventie

Hey je moet me maar ploinken op naam, want ik post vanaf 2 IP's.

Ik prefereer toch het gebruik van variabelen buiten quotes, staat wat
netter en duidelijker.

--
Cheers, Maarten Wierda

"Won't you believe it. It's just my luck. No Recess." - K.D. Cobain

[GeertS]

On Mon, 19 May 2003 22:02:22 +0200, Maarten Wierda
<moart3nAT@norecessDOT.com> wrote:

>Leer jezelf trouwens af variabelen
>tussen quotes te gebruiken.

Wat is de reden hiervan eigenlijk?
Ik vraag me al lang af of er een voorkeur is en waarom.

mvg,
gs

[Marcus]

GeertS wrote:
> On Mon, 19 May 2003 22:02:22 +0200, Maarten Wierda
> <moart3nAT@norecessDOT.com> wrote:
>
>> Leer jezelf trouwens af variabelen
>> tussen quotes te gebruiken.
>
> Wat is de reden hiervan eigenlijk?
> Ik vraag me al lang af of er een voorkeur is en waarom.

Omdat het interpreteren langer duurt en omdat je sneller fouten maakt
(plus het levert lijk me ambigue situaties op)

Mark

[Daniel Tryba]

Marcus <doei@bannerswapnl.com> wrote:
>> Wat is de reden hiervan eigenlijk?
>> Ik vraag me al lang af of er een voorkeur is en waarom.
>
> Omdat het interpreteren langer duurt

Cijfers? String concats zijn immers ook niet gratis.

> en omdat je sneller fouten maakt (plus het levert lijk me ambigue
> situaties op)

Daar zijn de {} voor.

--

Daniel Tryba

[Marcus]

Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>>> Wat is de reden hiervan eigenlijk?
>>> Ik vraag me al lang af of er een voorkeur is en waarom.
>>
>> Omdat het interpreteren langer duurt
>
> Cijfers? String concats zijn immers ook niet gratis.

$a = time;
for ($x = 0;$x < 3000000;$x++){
print "hoi:$x\n";
}

$b = time;

for ($x = 0;$x < 3000000;$x++){
print 'hoi:' . $x . "\n";
}

$c = time;

print STDERR $a . ' ' . $b . ' ' . $c . ' ' . "\n";





[ Wrote 14 lines ]

mark@papyrus:~$ perl perltest.pl > /dev/null
1053729332 1053729453 1053729572

121 seconden voor de eerste variant
121 seconden voor de tweede variant

Dit komt redelijk overeen met de verklaring van een vriend van mij die
zij dat de door jou geprefereerde statements in compile-time om worden
gezet naar stringconcats.

Het lijkt erop dat het niet veel uitmaakt dus

In ieder geval blijf ik bij de string-concat methode, die is ook meer
compatible met andere talen... (java,basic,c)

Mark

[Daniel Tryba]

Marcus <doei@bannerswapnl.com> wrote:
>> Cijfers? String concats zijn immers ook niet gratis.
>
> $a = time;
> for ($x = 0;$x < 3000000;$x++){
> print "hoi:$x\n";
> }
>
> $b = time;
>
> for ($x = 0;$x < 3000000;$x++){
> print 'hoi:' . $x . "\n";
> }
>
> $c = time;
>
> print STDERR $a . ' ' . $b . ' ' . $c . ' ' . "\n";

> 121 seconden voor de eerste variant
> 121 seconden voor de tweede variant

Slechte tests, je weet nu niet wat je test: de print of het string
gebeuren. Maar in PHP is voor bovenstaande test een duidelijk verschil te
meten tussen ' en " (in het voordeel van '), maar naarmate je string
samenstelling complexer word verdwijnt het voordeel (10 variabelen in
1 string douwen en er is geen verschil meer waar te nemen).

> Dit komt redelijk overeen met de verklaring van een vriend van mij die
> zij dat de door jou geprefereerde statements in compile-time om worden
> gezet naar stringconcats.

Hoe weet je wat mijn preferenties zijn? Ik gebruik wat mij het best uitkomt.

> Het lijkt erop dat het niet veel uitmaakt dus
>
> In ieder geval blijf ik bij de string-concat methode, die is ook meer
> compatible met andere talen... (java,basic,c)

Strings in C? Maar bekijk het verschil eens tussen String en
StringBuffer in java, een stringconcat is in java *zeer kostbaar*.

public class StringTest
{
public static void main(String[] args)
{
long start,stop;
String str=new String();

start=System.currentTimeMillis();
for(int i=0;i<100000;i++)
{
str+="a";
}
System.out.println(str);
stop=System.currentTimeMillis();

System.out.println((stop-start)+" ms");
}
}

vs.

public class StringBufferTest
{

public static void main(String[] args)
{
long start,stop;
StringBuffer buf=new StringBuffer();

start=System.currentTimeMillis();
for(int i=0;i<100000;i++)
{
buf.append("a");
}
String str=buf.toString();
System.out.println(str);
stop=System.currentTimeMillis();

System.out.println((stop-start)+" ms");
}
}

Het resultaat is het zelfde, snelheidsverschil is een factor *HEEL VEEL*:

String:
374350 ms
real 375.25
user 367.15
sys 4.24

Buffer:
365 ms
real 1.37
user 0.83
sys 0.04

op een PIII 500.

Oorzaak is het feit dat Strings immutable zijn.

--

Daniel Tryba

[Marcus]

Daniel Tryba wrote:
> Marcus <doei@bannerswapnl.com> wrote:
>>> Cijfers? String concats zijn immers ook niet gratis.
>>
>> $a = time;
>> for ($x = 0;$x < 3000000;$x++){
>> print "hoi:$x\n";
>> }
>>
>> $b = time;
>>
>> for ($x = 0;$x < 3000000;$x++){
>> print 'hoi:' . $x . "\n";
>> }
>>
>> $c = time;
>>
>> print STDERR $a . ' ' . $b . ' ' . $c . ' ' . "\n";
>
>> 121 seconden voor de eerste variant
>> 121 seconden voor de tweede variant
>
> Slechte tests, je weet nu niet wat je test: de print of het string
> gebeuren.

het ging er gewoon om welk statement sneller is:

print "hoi:$x\n";
of
print 'hoi:' . $x . "\n";

en daarvoor volstaat de test prima.

> Maar in PHP is voor bovenstaande test een duidelijk
> verschil te meten tussen ' en " (in het voordeel van '), maar
> naarmate je string samenstelling complexer word verdwijnt het
> voordeel (10 variabelen in 1 string douwen en er is geen verschil
> meer waar te nemen).
>
>> Dit komt redelijk overeen met de verklaring van een vriend van mij
>> die zij dat de door jou geprefereerde statements in compile-time om
>> worden gezet naar stringconcats.
>
> Hoe weet je wat mijn preferenties zijn? Ik gebruik wat mij het best
> uitkomt.

Voorbarige conclusie, ik meende dat op te maken uit het voorgaande,
sorry

>> Het lijkt erop dat het niet veel uitmaakt dus
>>
>> In ieder geval blijf ik bij de string-concat methode, die is ook meer
>> compatible met andere talen... (java,basic,c)
>
> Strings in C? Maar bekijk het verschil eens tussen String en
> StringBuffer in java, een stringconcat is in java *zeer kostbaar*.
>
> public class StringTest
> {
> public static void main(String[] args)
> {
> long start,stop;
> String str=new String();
>
> start=System.currentTimeMillis();
> for(int i=0;i<100000;i++)
> {
> str+="a";
> }
> System.out.println(str);
> stop=System.currentTimeMillis();
>
> System.out.println((stop-start)+" ms");
> }
> }
>
> vs.
>
> public class StringBufferTest
> {
>
> public static void main(String[] args)
> {
> long start,stop;
> StringBuffer buf=new StringBuffer();
>
> start=System.currentTimeMillis();
> for(int i=0;i<100000;i++)
> {
> buf.append("a");
> }
> String str=buf.toString();
> System.out.println(str);
> stop=System.currentTimeMillis();
>
> System.out.println((stop-start)+" ms");
> }
> }
>
> Het resultaat is het zelfde, snelheidsverschil is een factor *HEEL
> VEEL*:
>
> String:
> 374350 ms
> real 375.25
> user 367.15
> sys 4.24
>
> Buffer:
> 365 ms
> real 1.37
> user 0.83
> sys 0.04
>
> op een PIII 500.

Hmm, ik moet maar eens naar die StringBuffer class kijken. Wat ik
trouwens bedoelde is dat bij printen je over het algemeen ook iets als
System.out.println("hoi:" + a) doet in Java.


> Oorzaak is het feit dat Strings immutable zijn.

Je bedoelt dat er elke keer een nieuw stringobject wordt gemaakt of zo?

Mark

[Daniel Tryba]

Marcus <doei@bannerswapnl.com> wrote:
>> Slechte tests, je weet nu niet wat je test: de print of het string
>> gebeuren.
>
> het ging er gewoon om welk statement sneller is:
>
> print "hoi:$x\n";
> of
> print 'hoi:' . $x . "\n";

Als je de thread even terug leest ging het IMHO over string
manipulatie/generatie MBT tot " vs. '

> en daarvoor volstaat de test prima.

De print is geheel overbodig, immers wat test je ermee? In jou voorbeeld
is het afhankelijk van hoe snel je shell een redirect doet.

>>> Dit komt redelijk overeen met de verklaring van een vriend van mij
>>> die zij dat de door jou geprefereerde statements in compile-time om
>>> worden gezet naar stringconcats.
>>
>> Hoe weet je wat mijn preferenties zijn? Ik gebruik wat mij het best
>> uitkomt.
>
> Voorbarige conclusie, ik meende dat op te maken uit het voorgaande,
> sorry

Dan zal ik ook maar even mijn preferentie verklappen: leesbaarheid.
-geen overbodig gebruik van escapes
-geen overbodig gebruik van concats
-geen overbodig gebruik van {/}

Hoe ik dat precies invul is variabel

>> Het resultaat is het zelfde, snelheidsverschil is een factor *HEEL
>> VEEL*:
>>
>> String:
>> 374350 ms
>> real 375.25
>> user 367.15
>> sys 4.24
>>
>> Buffer:
>> 365 ms
>> real 1.37
>> user 0.83
>> sys 0.04
>>
>> op een PIII 500.
>
> Hmm, ik moet maar eens naar die StringBuffer class kijken. Wat ik
> trouwens bedoelde is dat bij printen je over het algemeen ook iets als
> System.out.println("hoi:" + a) doet in Java.

Maak eens een testje waar je steeds een String print of waar je een
heel StringBuffer in 1 keer print. Maar het is natuurlijk van wat je wil
bereiken of het zinnig is om de output in 1 keer te flushen. Ben je bv
bezig met een tabel op aan het bouwen dan is het geen bezwaar om dat
eerst rustig in memory te doen en dan in 1 keer te flushen, immers de
meeste browser doen toch niet veel met een tabel totdat die gesloten
wordt (IIRC).

>> Oorzaak is het feit dat Strings immutable zijn.
>
> Je bedoelt dat er elke keer een nieuw stringobject wordt gemaakt of zo?

Correct. Daarom worden strings ook niet by reference meegeven zoals
normale objecten.

--

Daniel Tryba