---

Hvordan kan man tjekke at det er et gyldigt tal uden komme, punktum osv.

if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}

--
MVH
Michael
www.storkie.dk

---

Michael Korsgaard wrote:

> Hvordan kan man tjekke at det er et gyldigt tal uden komme, punktum osv.
> if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}

http://dk.php.net/manual/en/function.is-int.php

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik i front - <http://www.phonixfolk.dk/>
H.C. Andersen-Centret: <http://www.andersen.sdu.dk/>
Vi har killinger på Garion.dk: <http://garion.dk/>

---

Jesper Brunholm wrote:
> Michael Korsgaard wrote:
>
>> Hvordan kan man tjekke at det er et gyldigt tal uden komme, punktum
>> osv. if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}
>
> http://dk.php.net/manual/en/function.is-int.php
>
> mvh
>
> Jesper Brunholm
Virker ikke hvis Det er en streng af tal..... der skal noget regex til...

--
Hvem læser dette?
Tilykke du er den første:)
MVH Dan Molberg

---

Dan Molberg wrote:

>>http://dk.php.net/manual/en/function.is-int.php

> Virker ikke hvis Det er en streng af tal..... der skal noget regex til...

Er du ikke rar at uddybe den, IMHO udelukker det, at det er en streng,
at datatypen er int.

Som der står på den side som der er henvist til kan man detektere tal
hentet som parametre med is_numeric(), så jeg går ud fra at det ikke er
det du mener.

hvis det handler om '1,4,234,3' så ville jeg splitte arrayet op i poster
først, det er lettere.

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik i front - <http://www.phonixfolk.dk/>
H.C. Andersen-Centret: <http://www.andersen.sdu.dk/>
Vi har killinger på Garion.dk: <http://garion.dk/>

---

Jesper Brunholm wrote:
> Dan Molberg wrote:
>
>>> http://dk.php.net/manual/en/function.is-int.php
>
>> Virker ikke hvis Det er en streng af tal..... der skal noget regex
>> til...
>
> Er du ikke rar at uddybe den, IMHO udelukker det, at det er en streng,
> at datatypen er int.
>
> Som der står på den side som der er henvist til kan man detektere tal
> hentet som parametre med is_numeric(), så jeg går ud fra at det ikke
> er det du mener.
>
> hvis det handler om '1,4,234,3' så ville jeg splitte arrayet op i
> poster først, det er lettere.
>
> mvh
>
> Jesper Brunholm
Jeg regner med at Michael skal bruge det til form verifikation, så dur
is_int() ikke, så det er enten en regex eller is_numeric().
--
Hvem læser dette?
Tilykke du er den første:)
MVH Dan Molberg

---

Dan Molberg wrote:

> Jeg regner med at Michael skal bruge det til form verifikation, så dur
> is_int() ikke, så det er enten en regex eller is_numeric().

ok, men is_numeric er da stadig langt hurtigere end regex?

mvh

Jesper Brunholm

(PS - nu har jeg læst din signatur mindst 12 gange - hvad får dig til at
tro at jeg er den første? )

--
Phønix - dansk folk-musik i front - <http://www.phonixfolk.dk/>
H.C. Andersen-Centret: <http://www.andersen.sdu.dk/>
Vi har killinger på Garion.dk: <http://garion.dk/>

---

Jesper Brunholm wrote:
> Dan Molberg wrote:
>
>> Jeg regner med at Michael skal bruge det til form verifikation, så
>> dur is_int() ikke, så det er enten en regex eller is_numeric().
>
> ok, men is_numeric er da stadig langt hurtigere end regex?
Ja, men hvis man f.eks vil se om der er . og , i så dur is_numeric() ikke.
For os er 2.000,00 et tal, ikke? Men for is_numeric() er det ikke, og hvis
setlocal ikke er sat rigtigt vil en type casting give 2,0.

>
> mvh
>
> Jesper Brunholm
>
> (PS - nu har jeg læst din signatur mindst 12 gange - hvad får dig til
> at tro at jeg er den første? )
Det var en tidligere signatur som jeg gættede på folk ikke læste:D Det
virkede med garanti sådan:(

--
Hvem læser dette?
Tilykke du er den første:)
MVH Dan Molberg

---

On Mon, 6 Oct 2003 13:08:31 +0200
"Michael Korsgaard" <miv_k@hotmail.com> wrote:

> Hvordan kan man tjekke at det er et gyldigt tal uden komme, punktum
> osv.
>
> if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}
$streng)=1213223";
$foo=preg_match("/[0-9]+/",$streng,$match);
if ($streng==$match[1]){
   print "dette er et heltal";
} else print "denne streng indeholder andet end et heltal";

---

Kim Schulz wrote:

>>if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}
>
> $streng)=1213223";
> $foo=preg_match("/[0-9]+/",$streng,$match);
> if ($streng==$match[1]){
>    print "dette er et heltal";
> } else print "denne streng indeholder andet end et heltal";

Jeg går ud fra at parentesen i '$streng)=' er en fejl (?)

Er der en grund til at du mener preg_match() er bedre end is_int() eller
is_numeric() ?

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik i front - <http://www.phonixfolk.dk/>
H.C. Andersen-Centret: <http://www.andersen.sdu.dk/>
Vi har killinger på Garion.dk: <http://garion.dk/>

---

On Mon, 06 Oct 2003 14:27:42 +0200
Jesper Brunholm <nospam@brunholm-scharff.dk> wrote:
> Kim Schulz wrote:
>
> >>if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}
> >
> > $streng)=1213223";
> > $foo=preg_match("/[0-9]+/",$streng,$match);
> > if ($streng==$match[1]){
> >    print "dette er et heltal";
> > } else print "denne streng indeholder andet end et heltal";
>
> Jeg går ud fra at parentesen i '$streng)=' er en fejl (?)
>
> Er der en grund til at du mener preg_match() er bedre end is_int()
> eller is_numeric() ?

ja det er en fejl og nej ingen grund andet end at det blev nævnt at der
skulle bruges en form for regex

---

> Hvordan kan man tjekke at det er et gyldigt tal uden komme, punktum
> osv.
>
> if($tal == tal KUn tal){ echo "Gyldigt}else{ugyldigt}

(string)((int)$tal)==$tal

Hvilket f.eks. viser mine tidligere kommentarer om php og deres
uhensigsmæssige typehåndtering.
--
mvh. Jacob Larsen - Pornofilm.dk

---

On Mon, 6 Oct 2003 19:51:38 +0200, "Jacob Larsen"
<jacobl@(((FJERNDETTE)))cs.auc.dk> wrote:

>(string)((int)$tal)==$tal
>
>Hvilket f.eks. viser mine tidligere kommentarer om php og deres
>uhensigsmæssige typehåndtering.

Du kan da ikke både bevidst undlade at lave en typesammenligning, og
bagefter brokke dig over manglende typesammenligning?

(string)((int)$tal)===$tal
vil rigtigt nok fejle, hvis $tal er en int på forhånd.

--
- Peter Brodersen

Ugens sprogtip: hierarki (og ikke hieraki)

---

>> (string)((int)$tal)==$tal
>>
>> Hvilket f.eks. viser mine tidligere kommentarer om php og deres
>> uhensigsmæssige typehåndtering.
>
> Du kan da ikke både bevidst undlade at lave en typesammenligning, og
> bagefter brokke dig over manglende typesammenligning?
>
> (string)((int)$tal)===$tal
> vil rigtigt nok fejle, hvis $tal er en int på forhånd.

Jo det kan jeg sagtens, da der er gode grunde til at === ikke skal eksistere
sammen med ==
Der er store problemstillinger forbundet med at give folk flere muligheder
for typecheck. Desuden er der flere steder, der er typeproblemer end i
forbindelse med lighedsoperatoren.

Din kommentar viser bare, du ikke har overvejet problemstillingen eller er
en spaghettikoder.
--
mvh. Jacob Larsen

---

On Tue, 7 Oct 2003 00:11:03 +0200, "Jacob Larsen"
<jacobl@(((FJERNDETTE)))cs.auc.dk> wrote:

>Din kommentar viser bare, du ikke har overvejet problemstillingen eller er
>en spaghettikoder.

Tak ska' du ha'.

I henhold til PHP som en formparser, så synes jeg ikke, der er tale om
det store problem. Selvfølgelig kan sprog lære fra hinanden, men at
PHP er et "typesvagt" sprog, ser jeg ikke som en ulempe målt på en
absolut skala (jo, måske set fra en akademisk betragtning). Jeg har
det fint med bl.a. PHPs (og fx perls) cast-juggling - specielt fordi
jeg så blot har mulighed for at vælge et andet sprog, hvis jeg har
brug for mere kontrol.

Dertil kommer selvfølgelig, at det afhænger af hvilke projekter, man
arbejder på, om hvorvidt, det overhovedet er et problem i praksis.
Meget af diskussionen er reel nok på et teoretisk og akademisk plan
(og jeg vil da heller ikke opfordre folk til ikke at forstå forskellen
på forskellige typer), men i praksis klarer man sig ofte med meget
mindre. For mange websiders vedkommende - fx sider, der blot skal æde
et ID på en artikel eller deslige - kunne det fx være nok at kyle en
variabel igennem fx intval(). Hvis en bruger insisterer på at gå ind
på siden med "id=14dinmor", så har jeg ikke hovedpine over at han
skulle få siden med id 14 at se, fremfor en blank side.

Jeg har erfaret, at mange tjek baserer sig på at ville honorere en del
brugerfejl. Her mener jeg, at det ofte ikke er umagen værd at foretage
en række udtømmende tjek, i forhold til blot brutalt at tvinge en
variabel til fx at være en int, hvis det alligevel "burde" være det.


I øvrigt viser din kommentar, at du ikke har erfaring med PHP, eller
at du har samlivsproblemer - og så betaler du ikke licens. Og skal vi
så ikke begynde at opføre os ordentligt, i stedet for blot at prøve at
lyde overlegne ved at slynge bombastiske udsagn rundt omkring?

Kigger jeg tilbage på tidligere projekter, vil jeg vove at påstå, at
jeg kan stå inde for alle mine variables typer hele vejen igennem.
Problemet kan til gengæld opstå, ved at man - hvis man blot taster
derudaf, og reloader lidt nu og da - kan opleve en situation, hvor man
virker tættere på målet, end man reelt er. Dette kan utvivlsomt blænde
nogle folk.

--
- Peter Brodersen

Ugens sprogtip: hierarki (og ikke hieraki)

---

> I henhold til PHP som en formparser, så synes jeg ikke, der er tale om
> det store problem. Selvfølgelig kan sprog lære fra hinanden, men at
> PHP er et "typesvagt" sprog, ser jeg ikke som en ulempe målt på en
> absolut skala (jo, måske set fra en akademisk betragtning). Jeg har
> det fint med bl.a. PHPs (og fx perls) cast-juggling - specielt fordi
> jeg så blot har mulighed for at vælge et andet sprog, hvis jeg har
> brug for mere kontrol.

Jeg nævnte ikke typer i forhold til en PHP som en formparser. Det er jo ikke
ligefrem det eneste det kan bruges til. Ud fra dine eksempler lyder det ikke
til, du har brugt det til mere, så du har måske ikke oplevet disse problemer
endnu..

> Dertil kommer selvfølgelig, at det afhænger af hvilke projekter, man
> arbejder på, om hvorvidt, det overhovedet er et problem i praksis.
> Meget af diskussionen er reel nok på et teoretisk og akademisk plan
> (og jeg vil da heller ikke opfordre folk til ikke at forstå forskellen
> på forskellige typer), men i praksis klarer man sig ofte med meget
> mindre. For mange websiders vedkommende - fx sider, der blot skal æde
> et ID på en artikel eller deslige - kunne det fx være nok at kyle en
> variabel igennem fx intval(). Hvis en bruger insisterer på at gå ind
> på siden med "id=14dinmor", så har jeg ikke hovedpine over at han
> skulle få siden med id 14 at se, fremfor en blank side.
>
> Jeg har erfaret, at mange tjek baserer sig på at ville honorere en del
> brugerfejl. Her mener jeg, at det ofte ikke er umagen værd at foretage
> en række udtømmende tjek, i forhold til blot brutalt at tvinge en
> variabel til fx at være en int, hvis det alligevel "burde" være det.

Hvis du absolut vil snakke forms og lign. lowlevel-ting: Giv lige et eks. på
hvor du ikke mener validering af input er vigtigt i forbindelse med en form.
Det du har givet der er ikke ret sigende for større "projekter".

> I øvrigt viser din kommentar, at du ikke har erfaring med PHP, eller
> at du har samlivsproblemer - og så betaler du ikke licens. Og skal vi
> så ikke begynde at opføre os ordentligt, i stedet for blot at prøve at
> lyde overlegne ved at slynge bombastiske udsagn rundt omkring?

Som du tager op uden at undesøge resten af mit indlæg.

> Kigger jeg tilbage på tidligere projekter, vil jeg vove at påstå, at
> jeg kan stå inde for alle mine variables typer hele vejen igennem.

Man kan også være flere end bare dig. Dette giver f.eks. problemer i
forbindelse med overholdelse af kodestandarder og integrering af
delprojekter.

Hvis du påstår, at du altid har styr på typer, påstår du så også at kende
alle aspekter af problemerne indført af multipel nedarvning? Dette må jo
være det næste skridt.
--
mvh. Jacob Larsen

---

On Tue, 7 Oct 2003 18:24:19 +0200, "Jacob Larsen"
<jacobl@(((FJERNDETTE)))cs.auc.dk> wrote:

>Hvis du absolut vil snakke forms og lign. lowlevel-ting: Giv lige et eks. på
>hvor du ikke mener validering af input er vigtigt i forbindelse med en form.
>Det du har givet der er ikke ret sigende for større "projekter".

Jeg tror, du har brug for at læse, hvad jeg skriver. Selvfølgelig skal
data valideres eller sanitizes.

Jeg nævner, at jeg i en del tilfælde ikke ser behov for fx en større
omgang input-validering med regexps, etc., da man kan sanitize yderst
enkelt. Fx:

$articleid = intval($_REQUEST['articleid']);

--
- Peter Brodersen

Ugens sprogtip: hierarki (og ikke hieraki)

---

>> Hvis du absolut vil snakke forms og lign. lowlevel-ting: Giv lige et
>> eks. på hvor du ikke mener validering af input er vigtigt i
>> forbindelse med en form. Det du har givet der er ikke ret sigende
>> for større "projekter".
>
> Jeg tror, du har brug for at læse, hvad jeg skriver. Selvfølgelig skal
> data valideres eller sanitizes.
>
> Jeg nævner, at jeg i en del tilfælde ikke ser behov for fx en større
> omgang input-validering med regexps, etc., da man kan sanitize yderst
> enkelt. Fx:
>
> $articleid = intval($_REQUEST['articleid']);

Har jeg påstået man ikke kan det?
--
mvh. Jacob Larsen

---

On Tue, 7 Oct 2003 19:22:09 +0200, "Jacob Larsen"
<jacobl@(((FJERNDETTE)))cs.auc.dk> wrote:

>> $articleid = intval($_REQUEST['articleid']);
>Har jeg påstået man ikke kan det?

Sikkert ikke, men du bad mig om det: "Giv lige et eks. på hvor du ikke
mener validering af input er vigtigt i forbindelse med en form."

Jeg gav et eksempel på helt simpel sanitizing.

Jeg kan ikke se, at dine øvrige kommentarer har så meget at gøre med
den oprindelige spørger.

--
- Peter Brodersen

Ugens sprogtip: hierarki (og ikke hieraki)

---

>>> $articleid = intval($_REQUEST['articleid']);
>> Har jeg påstået man ikke kan det?
>
> Sikkert ikke, men du bad mig om det: "Giv lige et eks. på hvor du ikke
> mener validering af input er vigtigt i forbindelse med en form."
>
> Jeg gav et eksempel på helt simpel sanitizing.

Ok, men jeg sagde ikke, at man skulle undgå at lave simpel typecheck hvis
det er tilstrækkeligt. Mine kommentarer gik på håndteringen af typer i PHP.

> Jeg kan ikke se, at dine øvrige kommentarer har så meget at gøre med
> den oprindelige spørger.

Fint, så stopper jeg her.
--
mvh. Jacob Larsen

---

"Jacob Larsen" <jacobl@(((FJERNDETTE)))cs.auc.dk> writes:

> Jo det kan jeg sagtens, da der er gode grunde til at === ikke skal eksistere
> sammen med ==

Kunne du være rar at uddybe disse grunde?

> Der er store problemstillinger forbundet med at give folk flere
> muligheder for typecheck.

Kunne du være rar at uddybe disse grunde?

> Desuden er der flere steder, der er typeproblemer end i forbindelse
> med lighedsoperatoren.

Kunne du være rar at uddybe disse grunde?

> Din kommentar viser bare, du ikke har overvejet problemstillingen
> eller er en spaghettikoder.

Og dine kommentar viser
- at du ikke har begreb om netikette.
- at du ikke er [i stand til|for doven til] at argumentere for dine
påstande.

Og kan vi så ikke lade personangrebene ligge?

--
Med venlig hilsen
- Jacob Atzen

---

>> Jo det kan jeg sagtens, da der er gode grunde til at === ikke skal
>> eksistere sammen med ==
>
> Kunne du være rar at uddybe disse grunde?
>
>> Der er store problemstillinger forbundet med at give folk flere
>> muligheder for typecheck.
>
> Kunne du være rar at uddybe disse grunde?
>
>> Desuden er der flere steder, der er typeproblemer end i forbindelse
>> med lighedsoperatoren.
>
> Kunne du være rar at uddybe disse grunde?

Det værste er, at du jo er ligeglad hvad jeg mener.

>> Din kommentar viser bare, du ikke har overvejet problemstillingen
>> eller er en spaghettikoder.
>
> Og dine kommentar viser
> - at du ikke har begreb om netikette.
> - at du ikke er [i stand til|for doven til] at argumentere for dine
> påstande.

Ja, nu er jeg da først for "doven". Jeg gider ikke sidde og skrive en lang
forklaring om noget til en der alligevel ikke kan lide mig. Læs en
compilerbog + en bog om typer i C/C++ (da de har forstået det). Lav så et
programmeringssprog og forstå konsekvenserne. Derefter prøv at samarbejde
med folk ud fra OOA&D-metoden i forbindelse med flere forskellige
programmeringssprog og lignende projekter. Så vil du sikkert kunne se
problemer.
(Dette er ikke en provokation eller noget smart-ass halløj. Bare et
forslag.)

> Og kan vi så ikke lade personangrebene ligge?

En uskyldig sætning? Jeg mener desuden, at den første provokation kom fra
Peter, da han kom med et spg, der slet ikke var baseret på det jeg skrev.

Citat:
"Du kan da ikke både bevidst undlade at lave en typesammenligning, og
bagefter brokke dig over manglende typesammenligning?"

Selvfølgelig kan jeg da tillade mig det. PHP's "==" og "===" er jo netop en
del af problemet.

EOD
--
Jacob

---

"Jacob Larsen" <jacobl@(((FJERNDETTE)))cs.auc.dk> writes:

> >> Jo det kan jeg sagtens, da der er gode grunde til at === ikke skal
> >> eksistere sammen med ==
> >
> > Kunne du være rar at uddybe disse grunde?
> >
> >> Der er store problemstillinger forbundet med at give folk flere
> >> muligheder for typecheck.
> >
> > Kunne du være rar at uddybe disse grunde?
> >
> >> Desuden er der flere steder, der er typeproblemer end i forbindelse
> >> med lighedsoperatoren.
> >
> > Kunne du være rar at uddybe disse grunde?
>
> Det værste er, at du jo er ligeglad hvad jeg mener.

Nej. Jeg er faktisk oprigtigt interesseret i at høre dine argumenter.

> Ja, nu er jeg da først for "doven". Jeg gider ikke sidde og skrive
> en lang forklaring om noget til en der alligevel ikke kan lide
> mig. Læs en compilerbog + en bog om typer i C/C++ (da de har
> forstået det).

Jeg har skam både læst bøger om oversættere og C/C++. Jeg går ikke ud
fra det er nødvendigt at læse en bog der kun omhandler typer i C/C++
for at forstå problemstillingerne her.

Hvem er i øvrigt "de" og hvad er det "de" har forstået?

> Lav så et programmeringssprog og forstå konsekvenserne.

Det ville være en hel del lettere om du bare ville forklare mig
konsekvenserne.

> Derefter prøv at samarbejde med folk ud fra OOA&D-metoden i
> forbindelse med flere forskellige programmeringssprog og lignende
> projekter. Så vil du sikkert kunne se problemer.

OOA&D-metoden? Så vidt jeg ved er OOA og OOD bare begreber. Hvor kan
jeg læse nærmere om metoden? Jeg har samarbejdet med folk omkring både
C, C++ og Java projekter. Hvilke problemer skulle jeg kunne få øje på?

--
Med venlig hilsen
- Jacob Atzen