2009-02-11 68 views
23

Nie rozumiem motywacji autorów PHP do dodawania podpowiedzi typu. Szczęśliwie żyłem, zanim się pojawił. Następnie, jak to zostało dodane do PHP 5, zacząłem określać typy wszędzie. Teraz myślę, że to zły pomysł, o ile typowanie kaczek zapewnia minimalne sprzężenie między klasami i wykorzystuje modularyzację kodu i ponowne wykorzystanie.(Kiedy) powinienem użyć podpowiedzi typu w PHP?

Czuje się, jak wskazówki typu dzielą język na 2 dialekty: niektórzy ludzie piszą kod w stylu statycznego języka, z podpowiedziami, a inni trzymają się starego starego dynamicznego modelu językowego. Czy nie jest to sytuacja "wszystko albo nic"? Czy w razie potrzeby powinienem połączyć te dwa style?

Odpowiedz

35

Nie chodzi o pisanie statyczne vs dynamiczne, php jest wciąż dynamiczne. Chodzi o umowy na interfejsy. Jeśli wiesz, że funkcja wymaga tablicy jako jednego z jej parametrów, wymuś ją w definicji funkcji. Wolę zawieść szybko, niż później omijać funkcję.

(również pamiętać, że nie można określić typ podpowiedzi dla bool, int, string, pływak, który ma sens w dynamicznym kontekście.)

+2

Zgadzam się. Po prostu uważam, że wszystkie te ścisłe kontrakty są w jakiś sposób obce pierwotnemu językowi kaczemu. PHP jest już wystarczająco brzydki, a podpowiedzi typu sprawiają, że wygląda jeszcze bardziej jak kupa niespokrewnionych funkcji. –

+4

Nie wiem, PHP rośnie (OOP). Ścisłe interfejsy dla złożonych typów danych mają dla mnie sens. – Mario

+2

Poza tym, otrzymujesz to co najlepsze z obu światów, określasz rygoryzm tam, gdzie ma to znaczenie, lub nie, i pozostawiasz małą dynamikę. – Mario

15

Powinieneś używać podpowiedzi typu, gdy kod w twojej funkcji zdecydowanie zależy od typu przekazanego parametru. Kod wygenerowałby mimo to błąd, ale podpowiedź typu da lepszy komunikat o błędzie.

+1

Cóż, mój kod w PHP zależy tylko od obecności metod, które wywołuję przed przekazanym obiektem parametru. Po co ograniczać się do żądania określonego typu? –

+5

W takim przypadku utwórz interfejs dla twojego obiektu, który go zaimplementuje, i wpisz podpowiedź swojej funkcji o tej nazwie interfejsu. Solidny kontrakt. – Mario

+1

Prawda. Zawsze (no może zapisz kilka przypadków) typhint do interfejsów - nie konkretnych klas. – troelskn

0

Bez typu podpowiedzi byłoby niemożliwe dla IDE znać typ parametr metody, a tym samym zapewnia właściwą intellisense - twój edytor ma intellisense, prawda? ;). Należy powiedzieć, że po prostu założę, że IDE używają tego dla intellisense, ponieważ jest to pierwsze, jakie słyszałem o podpowiedziach typu w PHP (dzięki za podpowiedź btw).

+2

Istnieje adnotacja phpdoc dla tego –

+0

Prawda, ale komentarze nie są zwykle kodowane;). – Justin

5

Jeśli kiedykolwiek zdecydujesz się na podpowiedzi typu, zrób to za pomocą interfejsów zamiast klas konkretnych lub abstrakcyjnych. Powód jest prosty, PHP nie pozwala na wielokrotne dziedziczenie, ale pozwala na implementację wielu interfejsów. Więc jeśli ktokolwiek spróbuje użyć twojej biblioteki, nie będzie miał trudności z implementacją twojego interfejsu, w przeciwieństwie do przypadku, w którym musiałby rozszerzyć twoją klasę abstrakcyjną/konkretną, zważywszy, że już ją rozszerza.

10

Motywacją grupy PHP do dodawania podpowiedzi do typu było dostarczenie osobom przyzwyczajonym do programowania w stylu Java z inną funkcją, która sprawiłaby, że platforma stałaaby się bardziej znajoma, wygodna i atrakcyjna. To z kolei sprawiłoby, że PHP stałoby się bardziej "gotowe dla przedsiębiorstwa", co pomogłoby Zendowi w ich podstawowej działalności.

Marketing na bok, ma swoje zastosowania. Jeśli piszesz metodę, która działa na parametrze w określony sposób, który spowodowałby niezamierzone (często ciche) niepowodzenia, gdyby parametr był czymś innym, wówczas użycie podpowiedzi typu zapewnia, że ​​kod zostanie przerwany podczas rozwoju, a nie zerwania produkcji.

-2

Podpowiedź typu jest punktem debaty w naszej firmie (głównie ludzie z Jawy), a ja jestem bardzo old schoolowym programistą PHP (i programem w innych językach).

Moja rada to unikanie podpowiedzi typu i włączanie funkcji obsługi prób i chwytów w każdej złożonej funkcji.

Podpowiedź typów zmusza aplikację do polegania na środowisku obsługi wyjątków wywołujących, które jest ogólnie złe i przechodzi w niesprawdzone, podstawowy problem. W przypadku aplikacji internetowych powoduje to biały ekran śmierci, w przypadku partii kończy się po prostu fatalnym wyjściem bez logowania dobrych wiadomości w większości przypadków, a ty siedzisz drapiąc się w głowę, próbując odtworzyć problem użytkownika lub aplikacji, który jest zarządzany na twoim komputerze. z powrotem do rozwiązania.

Obsługa wyjątków lokalnych zapewnia bardziej kontrolowany scenariusz testowania, w tym śmieci w typach danych i śmieci w wartościach danych, co daje znacznie bardziej kompletny zestaw testów w porównaniu do trudnej do przetestowania ścieżki obsługi wyjątku w wywołującym, przekazując niepoprawne wpisz i spodziewaj się wyjątku.

Testowanie wyjątków również nie udaje się w wielu przypadkach z powodu problemów z wersją stosu (np. Niektóre wersje PHP, takie jak 5.4, nie przechwytują błędów "złapalnych śmiertelnych" we właściwy sposób, a ergo phpunit po prostu zrywa z testowaniem pakietów testowych. specyficzny problem, jednak z mojego doświadczenia wynika, że ​​podpowiedzi typu są po prostu zbędne, powodują, że ludzie, którzy są przyzwyczajeni do języka maszynowego, akceptują PHP lepiej, nie zdając sobie sprawy z tego wpływu, i powodują znacznie bardziej złożone scenariusze testowania (bardzo trudne do przetestowania wywołujących wywołujące wyniki ścieżki wyjątków).

Użytkownicy języka Java i innych języków pisanych na klawiaturze nie akceptują lub nie wiedzą, jak wykorzystać i wykorzystać domyślne parametry mieszane w PHP ... Będą się uczyć pewnego dnia, ale tylko wtedy, gdy objąć drogę PHP. ;-)

Najlepsze lekcje są wyciągane podczas opracowywania solidnych scenariuszy testowych opartych na jednostkach PHP, które zwykle rzucają światło na to, dlaczego podpowiedź typu jest bólem w tyłku związanym z testowaniem i powoduje znacznie więcej problemów niż dobrych ... Do każdego z nich, a moje aplikacje działają lepiej i bardziej niezawodnie, a testowanie okazuje się o wiele bardziej kompletne z ogólnie 100% pokryciem kodu, w tym ścieżkami catch w lokalnych funkcjach.

Powiązane problemy