lege string
Hoe declareren jullie een lege string?
Zo:
Code (php)
1
2
3
2
3
<?php
$foo = '';
?>
$foo = '';
?>
of zo:
Code (php)
1
2
3
2
3
<?php
$foo = (string) null;
?>
$foo = (string) null;
?>
En kan het kloppen dat deze laatste methode niet werkt bij het setten van een class property?
Dan krijg ik een syntax-error, of doe ik iets fout nu?
Gewijzigd op 19/10/2013 20:33:21 door Ozzie PHP
Beide varianten leveren overigens exact hetzelfde resultaat op als ik het var_dump.
Gewijzigd op 19/10/2013 21:08:51 door Ozzie PHP
Het kan overigens wel handig zijn in functiedeclaraties:
function doIets ((string) $x)
{
# Doe iets met $x
}
maar aan de andere kant kun je je afvragen of je het niet beter is om in de functie en/of bij de aanroep van de functie eerst te testen of $x een geldige waarde heeft.
Misschien scheelt het ook wel dat ik heb leren programmeren in strongly typed languages en pas de laatste 10-15 jaar met weakly typed languages werk.
Dit zie ik overigens vaker...
function doIets ((string) $x)
{
# Doe iets met $x
}
Maar eigenlijk klopt dat toch niet, dat je een variabele binnen een functie typecast? Wat ik bijv. wel eens bij voorbeelden van andere forumleden zie gebeuren is dit:
Wat hier gebeurt, is dat ieder argument wat in deze method wordt gestopt, wordt omgezet naar een integer. Volgens mij is dat niet de juiste manier van programmeren. Het lijk mij veel beter dat je eerst controleert of $page een integer is. Zo ja, dan pas geef je 'm door aan de method. Ben jij het daar mee eens?
Overigens zie ik geen principiële verschillen tussen het typecasten in de functiedeclaratie (zoals in mijn codefragment) en het typecasten in de functie zelf (zoals in jouw codefragment). Het grote verschil is hooguit dat als je het in de declaratie doet, de variabele meteen voor de gehele functie de getypecaste waarde heeft. Dat kan handig zijn, tenzij je ook nog een keer de oorspronkelijke waarde wilt weten. En de methode uit jouw codefragment is ook nog bruikbaar bij oudere PHP-versies; dat kan soms ook een voordeel zijn. ;-) Maar eigenlijk vind ik typecasten (of dat nu expliciet of impliciet is) een aanwijzing dat er iets niet goed zit in de code. En dat geldt dus ook (om weer terug te komen bij het oorspronkelijke bericht) voor het initialiseren van een lege string met (string)null.
Gewijzigd op 19/10/2013 22:58:45 door Willem vp
"En als je echt robuust bezig bent, controleer je het in de functie/method zelf ook nog een keer."
Dit doe ik niet... dan ben je dubbel bezig. Gewoon zorgen dat je input klopt :)
Code (php)
1
2
2
int cijfer
String woord
String woord
etc etc.. alleen nu jij komt met je stelling/vraag.. denk ik bij mezelf is het bij PHP wel echt nodig? ik moet zeggen als ik het in php zou moeten doen dan zou ik het alleen doen als ik het echt nodig heb en ik moet ook zeggen dat ik typecasten naar string eigenlijk nooit gebruik en een int wel. Het zou wel netter zijn als het verplicht was maar daarom is php dan ook een lazy language! en daar moeten we gebruik van maken vind je niet?
Als je in een functie iets gaat typecasten dan ben je niet goed bezig. Wat je dan eigenlijk zegt is "wat ik ook binnenkrijg, ik maak er een string/int van!" Nee, je moet juist zorgen dat de functie niks anders dan een string/int binnenkrijgt. Die controle moet je dus al eerder doen. En dan ben je goed bezig :)
Ozzie PHP op 19/10/2013 23:42:07:
je moet juist zorgen dat de functie niks anders dan een string/int binnenkrijgt.
Als je in je eentje een programma in elkaar draait kun je dat inderdaad wel stellen. Als je echter met meerdere programmeurs moet samenwerken, of je maakt bijvoorbeeld een library voor gebruik door anderen dan is dat niet iets wat je kunt afdwingen.
Ik ben dan ook eerder geneigd om controle op correcte input te doen in de functie zelf dan bij de aanroep. Dat heeft als voordeel dat je de output van een andere functie kunt chainen zonder dat je je druk hoeft te maken of je wel het juiste type parameter meegeeft aan een functie.
Een ander voordeel is dat wanneer je een functie 100x aanroept op verschillende plaatsen in je code, je maar op 1 plaats een controle op je parameters hoeft te doen. Dat scheelt heel wat regels code en levert dus overzicht en (statistisch) minder fouten op.
Gewijzigd op 20/10/2013 00:21:14 door Willem vp
Mag ik vragen wie? Naar mijn weten ben ik een van de enige die dit (typecasten) op het forum heeft gebruikt en ik zou dit nooit aanraden om te doen voor het maken van een lege steing.
>> Beide varianten leveren overigens exact hetzelfde resultaat op als ik het var_dump.
En dat komt door het zwakke van php, daar moet je leren doorheen te kijken.
Quote:
Als je in je eentje een programma in elkaar draait kun je dat inderdaad wel stellen. Als je echter met meerdere programmeurs moet samenwerken, of je maakt bijvoorbeeld een library voor gebruik door anderen dan is dat niet iets wat je kunt afdwingen.
Ja, ik maak het voor mezelf... dus voor mezelf kan ik het wel afdwingen.
Quote:
Een ander voordeel is dat wanneer je een functie 100x aanroept op verschillende plaatsen in je code, je maar op 1 plaats een controle op je parameters hoeft te doen
Daar heb je dan ook wel weer een punt. Maar stel dat je bijv. een setAge method hebt die de leeftijd van de gebruiker instelt. De gebruiker voert in plaats van z'n leeftijd per ongeluk z'n naam in. Dan stuur jij dus de naam (een string) naar de setAge method, die daar vervolgens niks mee kan. Het lijkt me toch echt handiger om van tevoren te weten of je wel een string hebt ontvangen. Zo niet, dan kun je een foutmelding tonen en het formulier opnieuw op het scherm tonen.
Quote:
maar ik hoor mensen hier op het forum wel eens zeggen dat optie 2 eigenlijk beter of netter is. Maar bij het setten van een property lijkt het (bij mij) niet te werken.
Wouter, ik weet niet of jij dat was. Zou goed kunnen hoor. Dat typecasten van een lege string heb ik volgens mij Ward eens "horen zeggen". Ik dacht dat hij er voorstander van was om $foo = (string) null te doen ipv $foo = '';
Maar anyhow... dit is dus de beste oplossing als ik jullie goed begrijp:
Code (php)
1
2
3
2
3
<?php
$foo = '';
?>
$foo = '';
?>
Ozzie PHP op 20/10/2013 00:51:17:
Maar stel dat je bijv. een setAge method hebt die de leeftijd van de gebruiker instelt. De gebruiker voert in plaats van z'n leeftijd per ongeluk z'n naam in. Dan stuur jij dus de naam (een string) naar de setAge method, die daar vervolgens niks mee kan. Het lijkt me toch echt handiger om van tevoren te weten of je wel een string hebt ontvangen. Zo niet, dan kun je een foutmelding tonen en het formulier opnieuw op het scherm tonen.
En dan nog. Als setAge niets met je input kan, kan hij dat middels een return value aangeven: Simpelweg 0 of -1 als de input fout is, of zelfs -1 voor "not a number", -2 voor te oud, -3 voor te jong, etc. Daarnaast kun je nog een property errstr setten waar de uitgebreide foutmelding in staat.
Nu is setAge misschien een net iets te eenvoudige functie, maar je zou functies kunnen bedenken waar veel meer randvoorwaarden gecheckt moeten worden. Het is dan best praktisch om dat in je functie/method te doen. En om zelf niet in verwarring te geraken is het dan ook handig om daar consequent in te zijn: dus altijd alles checken in je functies/methods. ;-)
Op het moment dat ik aan het programmeren ben, en ik zou een verkeerd argument aanleveren dan werkt mijn code niet zoals zou moeten. Dat constateer ik dus direct. En dan kan ik het probleem dus ook direct oplossen. Mijn motto is dus dat ik zelf altijd de juiste gegevens aanlever aan een functie. Jaaa... natuurlijk kun je in iedere functie gaan controleren of je de juiste argumenten hebt aangeleverd, maar dat betekent in feite dat je continu je eigen werk aan het controleren bent, en bovendien... als je argumenten fout zijn werkt je code niet en heb je dus snel genoeg in de gaten dat er iets niet klopt. Als je in iedere functie je argumenten gaat controleren dan ben je in mijn ogen eigenlijk aan het autorijden met zijwieltjes.
Het enige wat je in feite "extra" moet controleren is user-data. Dat zijn gegevens die je zelf niet in de hand hebt. Maar dan gaat mijn voorkeur er nog steeds naar uit om de data te controleren vóórdat je 'm een functie instuurt.
Ik denk dat je op deze manier de beste balans hebt tussen performance en waar nodig controleren.
Gewijzigd op 20/10/2013 13:55:31 door Ozzie PHP
2) Ja, ik controleer of de verplichte array keys bestaan