construct en properties
Tevens vraag ik me af of $firstName = (string) null kan. PHP heeft beperkte support voor het instellen van default values bij het declareren.
Ik heb dat ook geprobeer met functienamen, maar dat is niet altijd handig. Dan staan je getters bijvoorbeeld voor je setters. En hoe kun je iets getten als je het nog niet geset hebt.
Ook in css probeer ik dat te doen overigens. Alleen soms kan dat niet, vanwege overerving.
Wouter, niet helemaal mee eens....het zou in functies wel leuk zijn als je bijvoorbeeld een array verwacht dat je dan in je functiebody gewoon aangeeft: array $var....scheelt weer een controle...wil je de standaard exceptions van php niet..dan zijn er mogelijkheden om die af te vangen en anders te tonen of te laten mailen, of je gooit hem in een try catch...de error moet buiten de functie afgehandeld worden en niet binnen de functie (al ligt dat bij OO een klein beetje anders)
Quote:
het zou in functies wel leuk zijn als je bijvoorbeeld een array verwacht dat je dan in je functiebody gewoon aangeeft: array $var....scheelt weer een controle...
Ja, dat doe ik ook (ook met object type hinting). Ik bedoelde alleen om variabele te prefixen met een type, bijv. $sName en $iAge of $stringName en $intAge.
Quote:
wil je de standaard exceptions van php niet..dan zijn er mogelijkheden om die af te vangen en anders te tonen of te laten mailen, of je gooit hem in een try catch...
PHP heeft weinig standaard exceptions. PHP werkt qua fouten nog steeds op de manier van flat scripten, lekker errors gooien. De errors zijn voorzover ik weet niet op te vangen in een try catch, je zou een eigen error_handler moeten maken die de errors omzet in de speciale errorexception.
Wouter J op 02/01/2013 15:19:24:
Namen prefixen met het type ben ik altijd grote tegenstander van, PHP is een lazy-type taal en daar moet je leuk gebruik van maken en niet dat stomme strict-type van die C talen in gooien :)
Wat bedoel je precies?
Als je hebt over prefixen van namen van variabelen kan ik het met je eens zijn.
Maar ik vind het stict-typing (en het vooraf declareren ervan) van variabelen niet stom, sterker nog ik heb dat liever.
Gewijzigd op 02/01/2013 19:21:41 door Ger van Steenderen
Ger van Steenderen op 02/01/2013 19:10:26:
Wat bedoel je precies?
Als je hebt over prefixen van namen van variabelen kan ik het met je eens zijn.
Maar ik vind het stict-typing (en het vooraf declareren ervan) van variabelen niet stom, sterker nog ik heb dat liever.
Wouter J op 02/01/2013 15:19:24:
Namen prefixen met het type ben ik altijd grote tegenstander van, PHP is een lazy-type taal en daar moet je leuk gebruik van maken en niet dat stomme strict-type van die C talen in gooien :)
Wat bedoel je precies?
Als je hebt over prefixen van namen van variabelen kan ik het met je eens zijn.
Maar ik vind het stict-typing (en het vooraf declareren ervan) van variabelen niet stom, sterker nog ik heb dat liever.
@Ger ik ben het met je eens dat
veel mooier is dan
maar elk voordeel heeft zijn nadeel. zo kan je in stricte talen zoals Java die waarde niet gelijk echoen op het scherm als bijv
maar dan heb je ( in java bv )
en dit ook met misschien andere varianten hiervan..
ik denk dat Wouter dit bedoelt? of iets in die richting?
Quote:
Maar ik vind het stict-typing (en het vooraf declareren ervan) van variabelen niet stom, sterker nog ik heb dat liever.
Het is mooier, maar soms heb ik veel liever het lazy-typing. Bijv. een filesystem klasse die zou bij remove een string met een filenaam kunnen hebben, maar ook een array met bestandsnamen. Om die variabele dan zo strict te definiëren vind ik stom.
Ik had eigenlijk ook liever strong typing gezien in PHP, maar dat zal helaas nooit komen omdat dan geen enkele php code meer werkt :P
Ik kwam net een stukje code tegen waar de class properties achter elkaar werden gedeclareerd.
Dus niet zo:
maar zo:
Ik heb het nog niet eerder gezien zo. Kan dit gewoon?
Gewijzigd op 06/01/2013 02:07:12 door Ozzie PHP
Ja, dat kan gewoon. Maar het is niet volgens de algemene PHP standaard (PSR) en daarom ga je het eigenlijk nergens zien.
Van de andere kant neemt het wel minder ruimte in als je veel class properties hebt.
Je class wordt minder "hoog".
dit artikel uitlegt waarom je in JS meerdere vars en niet var foo, bar; moet gebruiken
Ja, maar waarom het niet aangeraden wordt is om dezelfde redenen als De 1e reactie op het artikel daarentegen, stelt als tegenargument dat er minder code getypt hoeft te worden en dat de class properties in 1x worden geparst. Dit alles zou dan weer snelheidswinst opleveren. Nou gaat dit over javascript, maar vraag me af of dat in php ook zo is.
zucht... daar komt het snelheidsmonster in Ozzie weer naarboven, dacht dat ie daar vanaf was gestapt
Ozzie, als je een snel script wilt maken moet je stoppen met OO, het levert namelijk alleen maar tijdverlies op. Tevens zou zoiets zo'n extreme micro-optimalisatie zijn dat het niet eens in mij op zou komen.
En minder code typen? Dat is ook iets wat OO de eerste keer niet heeft, dus daar moet je dan ook maar vanaf. Ik bedoel, in onze Request klasse van het vorige topic hebben we nu een speciale createFromGlobals method moeten maken die we net zo goed in de constructor konden verwerken, bespaard weer heel wat tekens code.
Maar ik overweeg altijd even de voor- en nadelen. En uiteindelijk valt het kwartje dan wel de goede kant op hoor... don't worry. Hahaha... moest wel erg om je reactie lachen :D
Als ie maar geen cookie monster wordt ;-)
:D