Kdo nemá phpstorm, může použít:
https://github.com/VitexSoftware/phpunit-skeleton-generator
Aktivně jej používám z netbeans. Pull requesty příjmám.
Také existuje služba https://phpunitgen.io
AFAIK od 7.0 nebo 7.1., ale nevim jestli necemu pomahaji. podle mych zkusenosti, ve webovych aplikacich, komunikujicich s databazi nejde vse staticky otypovat.
teoreticky to "jde", kdyz pro kazdy dotaz rucne definujete typ vysledku, ale ten vubec nemusi odpovidat skutecnemu vysledku dotazu.
@A.P.Hacker
Něco takového [1] v jakékoliv formě, třeba Doctrine [2] v případě php?
[1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping
[2] https://www.doctrine-project.org/
@A.P.Hacker
addSelect neznám, nicméně nevím, proč by to nemělo fungovat. Doctrine mapuje objekty (Entity) na databázový model, zjednodušeně řečeno. Není nic mezi tím.
Nehledě na to, že můžete použít nějaký vlastní mapper/parser na jakýkoliv dotaz vrácený databází, nebo \PDO::fetch() s mapováním na objekty ...
Nevím, v životě jsem neviděl, že by nějaká databázová odpověď nešla přetypovat podle jakéhokoliv předpisu.
idealni by bylo, kdyby linter nebo compiler dokazal odvodit typ odpovedi a nemuselo se to pretypovavat rucne.
Tak type-hinty nejsou jen o "statickém" typování. V Pythonu je používám i pro orientaci v kódu. IDE to pomáhá a mě taky a přitom mypy třeba ani nepoužiju. Zapisovat tohle do dokumentace mi přišlo vždycky na hlavu, když to můžu napsat přímo do signatury. Lepší než nic. Python je můj denní chleba, ale ve Scale/Rustu jsem si nevšiml, že by něco nešlo otypovat, tak proč by to nešlo i jinde?
5. 11. 2021, 22:00 editováno autorem komentáře
@uetoyo
Jasně že to jde, všechno je totiž nějaký typ, resp. má nějakou reprezentaci.
5. 11. 2021, 22:49 editováno autorem komentáře
Typy se začly používat od doby, co je php umí :)
Tak třeba phpstorm mi ukáže už při psaní, že do nějaké funkce cpu něco, co tam nemá být. Našeptává mi parametry funkce. Při běhu kódu to vyhodí výjimku, když si definuju parametr funkce jako float, ale objeví se tam string (typicky cena produktu je na desetinná místa a oddělovač musí být tečka, ne čárka).
Array už není jen array, ale jako arraylist může mít svůj typ.
příklad:
$v1 = 156;
$v2 = "bublina";
$result = $v2 / $v1;
Výsledek není chyba, ale 0. Pokud obrátím čitatele a jmenovatele, zahlásí chybu dělení nulou.
To samé, když je v ceně mezera, které si na vstupních datech nemusíte všimnout, tak výsledek je úplně mimo:
$v1 = "1 0";
$v2 = "10";
$result = $v2 / $v1;
AFAIK PHP Storm umelo cist typy v komentarich davno pred podporou v jazyku, a nebylo to uplne stejne.
@Franta Pecka
Pro PhpStorm bych vám doporučil plugin Php Inspections (EA Extended) pokud jej už nepoužíváte
Typy v PHP je možné používať už od verzie 5.0 vydanej pred 17 rokmi, takže celú večnosť. Typová podpora v 5.x verziách bola ale relatívne obmedzená a preto málo používaná v praxi.
Od verzie 7.0, vydanej pred 6 rokmi, je tejto časti jazyka venovaná masívna pozornosť a každý release prináša nové vylepšenia typového systému. V súčasnosti vytváraný PHP kód je už preto písaný zvyčajne ako plne otypovaný.
Evolúcia typov v PHP:
https://www.phpclasses.org/blog/post/1047-php-8-type-hinting.html#th_version
6 let ... to to letí ... před php 7 se typy v uživatelském kódu prakticky nepoužívaly, někteří tak píší dodnes, a v 7 stále nemusíte používat typování - pokud neimplementujete nějaké rozhraní v jakékoliv formě ...
Děkuji všem čtenářům, kteří již ohledně typů odpověděli za mne.
Z mého pohledu je použití typů ve výkladu jazykových konstrukcí vhodné, protože to napomáhá k pochopení jejich významu.
No a pragmaticky vzato - pokud do Php, ve kterém typy nebyly, tam jeho tvůrci typy dodatečně přidávají, tak to bude mít nepochybně nějaký racionální důvod.
Pavel Herout