[php] declaratie van functie argumenten

[kluyze]

Ik zit met het volgende, ik wil een soort van engine maken voor een website geschreven in php. Hiervoor ben ik momenteel bezig met het mysql database gedeelte op te zetten met een soort van template opzet. Ik wil dus gewoon dat de database gemakkelijk in te stellen is en dat de site weet hoe de database eruit ziet aan de hand van een aantal template bestanden.

Tot zover een beetje de achtergrond van het project, het probleem is het volgende. Ik ben een aantal mysql wrapper functies aan het maken die moeten checken of de data die ik meegeef ook werkelijk in die database.tabel kan en mag.
Maar daar loop ik ergens tegen een probleem dat wat onduidelijkheid geeft in de foutmelding en op bronnen op het net.

Ik ben gewoon om in andere talen de argumenten in een functie te declareren met de types van de variabelen. Maar normaal gezien doe ik dit niet in php en het lijkt volgens de documentatie op php.net niet de gewoonte, maar andere bronnen laten toch blijken dat het mogelijk is. Aangezien dat duidelijker is kwa code zou ik graag de functies als volgt schrijven.

PHP:

function mysql_query_db(string $database, string $table, string $query, array $values)

Alleen lijkt dit niet te lukken, ik krijg daarbij een foutmelding:

code:

Catchable fatal error: Argument 1 passed to mysql::mysql_query_db() must be an instance of string, string given, called in ...

Dus dat hij een string verwacht en in de plaats een string krijgt Dus het lijkt erop dat php geen probleem heeft met de syntax in de functie declaratie.
Ik heb hier laatst ook al eens achter gezocht toen ik de foutmelding kreeg met een 'pass by reference' probleem in een php-lib en toen was de oplossing een typecast dus php moet met variable types om kunnen.

Met een ander type van variabele gaat het trouwens ook niet, als ik zeg 'int' of 'integer' geeft hij een gelijkaardige fout.

Nog wat verdere informatie:
php: 5.2.6
apache: 2.2.8
os: xp sp3 (maar moet ook runnen op een apple (leopard) en een linux bak(fc6 of fc8) met dezelfde versies van php en apache)
Ik gebruik dreamweaver CS3 om te coden maar dat heeft er weinig mee te maken
en de functie waar het over gaat zit in een klasse 'mysql' en wordt opgeroepen met de functie:

PHP:

$mysql->mysql_query_db("dev_db", "data_incoming", "select", $values);

Wat ik ook al heb getest is om de declaratie van de variabelen buiten de functie te doen, maar dat lijkt hij helemaal niet graag te hebben.

PHP:

string $database = "dev_db";

Is er misschien ergens een extra instelling in php.ini dat ik moet zetten hiervoor of een optie dat ik moet meegeven in de ./configure

Zo, dat is denk ik wel genoeg informatie. Ik zou niet onmiddelijk weten wat nog relevant is ... dus als iemand een idee heeft of het zelfs mogelijk is en hoe dat dan juist moet. php.net geeft nergens of en hoe een type declaratie kan of moet. Er zijn wel wat andere site's die het doen op dezelfde manier als ik probeer maar hoe dat dan lukt is me een raadsel. Misschien is het iets van een oude php versie of moet het ingesteld worden in de php.ini, ik zou het graag weten.

[ACM]

Hij verwacht een instance van string. Niet een string, en jij geeft wel een string.

En aangezien jij waarschijnlijk geen 'string'-klasse hebt is die melding op zich heel logisch, beetje jammer alleen dat je ook geen string-klasse kan maken en de melding dus best wat duidelijker had gekund...

Vziw kan je iig geen type hints voor scalar variabelen meegeven. Wat wel erg handig is met de betere IDE's is dat de met phpdoc opgegeven definities wel in de code-highlighting e.d. terugkomen.

[ Voor 23% gewijzigd door ACM op 09-07-2008 21:29 ]

[TeeDee]

Dus als ik je goed begrijp wil je PHP eigenlijk strong typed hebben? Afaik kan dat niet. Een niet ideale oplossing zou zijn een fatsoenlijke documentatie _en_ correct casten.

[kluyze]

Hmm, dus dat gaat alleen met eigen klassen en niet de standaard types van php, dat is ook stom. Zou een wat extra beveiliging geven bij het gebruik van de functies. Ik vreesde er al voor maar ik hoopte toch nog dat het mogelijk was.

Zelf een 'string' klasse maken is natuurlijk ook geen oplossing. Dat maakt het gebruik van de klasse alleen maar moeilijk.

Dan maar in de functie zelf een goede controle van de variabelen. Dat was ik toch van plan aan de hand van de template bestanden maar nu moet het iets uitgebreider.

[SchizoDuckie]

kluyze schreef op woensdag 09 juli 2008 @ 21:42:
Hmm, dus dat gaat alleen met eigen klassen en niet de standaard types van php, dat is ook stom. Zou een wat extra beveiliging geven bij het gebruik van de functies. Ik vreesde er al voor maar ik hoopte toch nog dat het mogelijk was.

Zelf een 'string' klasse maken is natuurlijk ook geen oplossing. Dat maakt het gebruik van de klasse alleen maar moeilijk.

Dan maar in de functie zelf een goede controle van de variabelen. Dat was ik toch van plan aan de hand van de template bestanden maar nu moet het iets uitgebreider.

Klopt, zo is PHP nou eenmaal

Wat je zou kunnen doen is een __get en __set aanmaken binnen je (eventueel base) class die elke variabele controleert op het juiste type (is_array, is_numeric, etc) a.d.h.v. een array die je definieert binnen je class

[curry684]

ACM schreef op woensdag 09 juli 2008 @ 21:27:
Vziw kan je iig geen type hints voor scalar variabelen meegeven.

Scalar is niet de goede term hier - je mag type hinting op arrays en classes, niet op native datatypes (dat is ook echt documented de uitzondering).

Maakt het hele verhaal type-hinting inderdaad wat nutteloos in PHP's huidige implementatie

[MichelVH]

curry684 schreef op donderdag 10 juli 2008 @ 09:11:
[...]
Maakt het hele verhaal type-hinting inderdaad wat nutteloos in PHP's huidige implementatie

Niet helemaal he... voor alle native types bestaat een conversie, dus als jij een string verwacht maar er wordt een int gegeven wordt die automatisch geconverteerd. Voor arrays en objecten bestaat die conversie natuurlijk niet, dus dan krijg je problemen als je een object verwacht en er wordt een native type gegeven.

[curry684]

Dan ga je voorbij aan de situaties waarbij het wel degelijk handig is om een specifiek datatype af te dwingen, zoals in gevallen waar je niet wilt dat '123abc' volautomatisch naar integer 123 wordt omgezet. Daarnaast heb ik nog goede hoop dat PHP op een dag ook volwassen taalelementen gaat krijgen als method overloading, en dan is strict type hinting op native types ook wel degelijk zeer handig.

[Voutloos]

MichelVH schreef op donderdag 10 juli 2008 @ 09:22:
[...]
Niet helemaal he... voor alle native types bestaat een conversie, dus als jij een string verwacht maar er wordt een int gegeven wordt die automatisch geconverteerd.

Nee, die wordt niet meteen geconverteerd, maar enkel pas bij bepaalde statements in die functie. En dan heb je misschien al lang en breed een aanname gemaakt. Jouw punt kan ook een argument zijn om het wel te ondersteunen, want het kan immers toch meteen gecast worden. (note dat dat imo ook bepaald niet ideaal gedrag is)

edit:
bovenstaande is dus met Curry.

Een functie heeft een bepaald contract, met name de te krijgen input en output, en zelfs met default De Heilige Weak-Typing en Conversie features is het helemaal geen gek idee om een strictere definitie in ieder geval mogelijk te maken.

curry684 schreef op donderdag 10 juli 2008 @ 09:26:
Daarnaast heb ik nog goede hoop dat PHP op een dag ook volwassen taalelementen gaat krijgen als method overloading, en dan is strict type hinting op native types ook wel degelijk zeer handig.

Die hoop heb ik ook, en oa met genoemde wensen. Maar het zal pas na PHP 6 en een zeer sterke wijziging in de houding van een paar core devvers kunnen komen.

[ Voor 22% gewijzigd door Voutloos op 10-07-2008 09:40 ]

[MichelVH]

Voutloos schreef op donderdag 10 juli 2008 @ 09:31:
[...]
Nee, die wordt niet meteen geconverteerd, maar enkel pas bij bepaalde statements in die functie. En dan heb je misschien al lang en breed een aanname gemaakt.

Ik doelde dan ook op het gebruik van een argument in de functie Bij objecten wordt dat problematisch, omdat je bijv. ook functies op een object wilt aanroepen.

Jouw punt kan ook een argument zijn om het wel te ondersteunen, want het kan immers toch meteen gecast worden. (note dat dat imo ook bepaald niet ideaal gedrag is)

Dan is het hele principe van een type afdwingen toch zinloos als er alsnog automatisch gecast wordt

Die hoop heb ik ook, en oa met genoemde wensen. Maar het zal pas na PHP 6 en een zeer sterke wijziging in de houding van een paar core devvers kunnen komen.

Eens Ik snap inderdaad niet waarom ze het op z'n minst mogelijk maken om ook native types af te dwingen, je hoeft het natuurlijk niet te gebruiken als je PHP als pure weak-typed taal wilt gebruiken, maar de devvers die wat meer willen afdwingen zouden er wel erg mee geholpen zijn...

Ik reageerde vooral op de opmerking van curry684 dat de huidige implementatie een beetje nutteloos is

[ Voor 4% gewijzigd door MichelVH op 10-07-2008 10:28 ]

[Icelus]

Zou dit geen problemen opleveren bij bestaande code?
MySQL geeft bijvoorbeeld álle opgehaalde gegevens terug als strings. Een functie aanroepen die een integer verwacht met een ID uit deze gegevens zou dan een foutmelding opleveren.

[TeeDee]

Icelus schreef op donderdag 10 juli 2008 @ 10:47:
MySQL geeft bijvoorbeeld álle opgehaalde gegevens terug als strings.

Que? Zeg jij nu dat MySQL niet eens fatsoenlijke datatypes teruggeeft, of bedoel je te zeggen dat alles wat door een (bijv.) mysql_query_db(...) als string terugkomt. Dan ligt het namelijk niet aan MySQL, maar, daar issie weer, aan PHP.

Een functie aanroepen die een integer verwacht met een ID uit deze gegevens zou dan een foutmelding opleveren.

Een fatsoenlijke IDE icm een goede documentatie (zoals ACM aangeeft) zou daar al het e.e.a. aan moeten kunnen doen.

[Icelus]

TeeDee schreef op donderdag 10 juli 2008 @ 10:53:
[...]

Que? Zeg jij nu dat MySQL niet eens fatsoenlijke datatypes teruggeeft, of bedoel je te zeggen dat alles wat door een (bijv.) mysql_query_db(...) als string terugkomt. Dan ligt het namelijk niet aan MySQL, maar, daar issie weer, aan PHP.

MySQL geeft het inderdaad ‘goed’ terug; PHP zet ze om naar strings.

[Voutloos]

MichelVH schreef op donderdag 10 juli 2008 @ 10:26:
Ik reageerde vooral op de opmerking van curry684 dat de huidige implementatie een beetje nutteloos is

Je wekte de indruk dat het bij deze types niet nuttig/nodig is en dat is het dus wel.

Icelus schreef op donderdag 10 juli 2008 @ 11:07:
[...]
MySQL geeft het inderdaad ‘goed’ terug; PHP zet ze om naar strings.

En daarom wordt er gesleuteld aan nieuwe mysql client libs welke meer native zijn. Zoals mysqlnd, welke meer native is, de Zend engine gebruikt, zodat de mermoy limit ook hier van toepassing is en read only buffers gebruikt kunen worden. Dat laatste betekent dat je resultset een keer minder gekopieerd hoeft te worden, wat geheugen en performance scheelt. En de lijst gaat door en door met allerlei goede ideeen, maar voorlopig is het toch nog niet af.

Functioneel gezien overigens allemaal redelijk offtopic, want bij het ophalen van dat Id veld kan je nu ook gewoon zsm een int cast doen.