DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   type hinting in php 5.3 (http://www.devprotalk.com/showthread.php?t=8340)

ivanhoe 20. 01. 2010. 15:20

type hinting in php 5.3
 
nemam 5.3 pri ruci da probam, jel dodat na kraju type hinting u funkcijama i za integer, string, boolean i sl. tipove?

Citam ovde nesto o tome kako je to bilo predlozeno da radi, i moram priznati da mi se ne dopada uopste... naravno, bolje bar neki type hinting, nego nikakav, ali mi se cini kao da ovakvo resenje nema mnogo veze sa filozofijom php-a.

Po ovom predlogu ako je f-ja definisana kao
PHP kôd:

function bla(int $a) {..} 

poziv tipa bla('1') ce da baci gresku. To je ok za jezike koji imaju zakucane tipove podataka, tamo takvo ponasanje ima smisla, ali posto je u php-u za funkcionalnost programa apsolutno nebitno da li je 1 ili '1', a 99% podataka sa kojima se radi su stringovi (jer $_POST i $_GET uvek vracaju string), onda bi (IMHO) ipak trebalo type-casting implementirati malo inteligentnije, da se gleda da li prosledjena vrednost moze pravilno da se castuje, a ne sam tip podatka.

Zapravo ako bi to tako uradili mislim da bi to bila jedna od najgenijalnijih izmena u PHP-u u poslednje vreme, jer bi ustedela gomilu provera, samo definises da u funkciji ocekujes nesto sto je validan integer, i ne moras da brines o tome vise, ni u samoj funkciji, ni kod pozivanja. Plus mnogo je brze da to proverava kompajler nego da se rucno pisu te provere.

Sta vi mislite?

agvozden 20. 01. 2010. 16:26

Mislim da se striktnim definisanjem moze doci i do odredjenog nivoa sigurnijeg koda.
Ionako mnogi vrse proveru prilikom primanja parametara. Ukoliko od $_POST ocekujes celi broj onda ces ga i provuci kroz int()... a opet to sve u vecini slucajeva treba provuci kroz bazu. Ukoliko radis sa postgresom tek onda dolazi do problema.
Odgovarala bi mi i definicija tipova podataka u samim definicijama clanova klase. Tako ne bih morao da upisujem pomocne komentare koji je tip podataka.

LiquidBrain 20. 01. 2010. 17:35

Zbog cega je problem sa postgresom?

ivanhoe 20. 01. 2010. 22:16

Citat:

Originalno napisao agvozden (Napišite 78707)
Odgovarala bi mi i definicija tipova podataka u samim definicijama clanova klase. Tako ne bih morao da upisujem pomocne komentare koji je tip podataka.

da, o tome sam i ja razmisljao, a to bi omogucilo i IDE da proverava varijable i odmah upozorava na probleme...

bluesman 20. 01. 2010. 22:54

Pazi nije samo to, fora je sto ako imas type hinting ovako:

PHP kôd:

function test (string $param)
{
    return 
$param;


i ako proslediš običan string ovako:

PHP kôd:

echo test ("proba"); 

Prijaviće error da parametar nije string instance: "...must be an instance of string, string given..."

Ne radi čak ni ovo:

PHP kôd:

$t = (string) "proba";
echo 
test ($t); 

pa ni ovo:
PHP kôd:

echo test ((string) "proba"); 

Jednostavno ne mogu se type-hintovati skalarne vrednosti, samo objekti i array:

PHP kôd:

function test (array $param)
{
    return 
$param;
}

print_r (test (array('proba'))); 

^ to će da radi.

E sad ... ovo za string, int ... uopšte mi nije jasno zašto je to tako.

sinisabobic 22. 01. 2010. 13:01

Nisam siguran al mislim da se od 5.1 verzije nista nije menjalo po tom pitanju sto znaci da string i integer ne rade jer nisu jos podrzani...

ivanhoe 22. 01. 2010. 22:32

@blues: To znaci da nisu jos dodali ovaj patch koji je predlagan, ima gore link u mom prvom postu sa opisom kako je to bilo zamisljeno da se implementira za int i string. Iskreno mozda je i bolje sto nisu menjali, posto mi se taj doticni predlog i ne svidja narocito.

bluesman 22. 01. 2010. 23:15

Ne vidim ja nešto posebno sporno sa ovim predlogom. To će smanjiti i one klasične greške pri validaciji input-a. Tačno je da je većina stvari iz request, pa samim tim i string, zato dobar kod uvek ima validaciju tipa podataka pre nego što ga koristi, oviakvim predlogom može da se smanji i svaka funkcija za po red-dva. Ako ja moram na početku svake funkcije:

PHP kôd:

function getById ($id

da radim

PHP kôd:

$id intval($id); 

Sa ovakvom deklaracijom:

PHP kôd:

function getById (int $id

mogao bih da preskočim taj red sa intval() ako se varijabla automatski konvertuje u int.

Meni je veći problem ovo kako je sada implementirano, ni na nebu ni na zemlji.

ivanhoe 23. 01. 2010. 03:02

fora je sto ne mozes da preskocis, i dalje bi morao da uradis intval($id) pre nego sto ga prosledis f-ji, jer bi ti inace bacila gresku. Ne kazem da je to lose, ali bilo bi bolje da uopste ne moras da konvertujes nesto u int, a da opet imas automatsku proveru da je vrednost ocekivanog tipa

jablan 23. 01. 2010. 07:33

Jel vama taj type weakness u PHP-u stvarno toliko znači?


Vreme je GMT +2. Trenutno vreme je 19:43.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.