Dlaczego podpisy funkcji PHP są tak niespójne? [Zamknięte]

Przeglądałem niektóre funkcje PHP i nie mogłem nie zauważyć:

<?php
function foo(&$var) { }

foo($a); // $a is "created" and assigned to null

$b = array();
foo($b['b']);
var_dump(array_key_exists('b', $b)); // bool(true)

$c = new StdClass;
foo($c->d);
var_dump(property_exists($c, 'd')); // bool(true)
?>

Zwróć uwagę na funkcję array_key_exists()i property_exists(). W pierwszym z nich nazwa właściwości (klucz do tablicy) jest pierwszym parametrem, natomiast w drugim jest drugim parametrem. Intuicyjnie można oczekiwać, że będą mieli podobny podpis. Może to prowadzić do zamieszania, a czas opracowywania może zostać zmarnowany przez wprowadzenie tego typu poprawek.

Czy PHP czy jakikolwiek inny język nie powinien rozważać spójności podpisów powiązanych funkcji?

To, co proponujesz, zasadniczo zmienia sygnatury na wiele istniejących funkcji. Pomyśl przez chwilę, jaki wpływ miałby to na istniejący kod. Załóżmy teraz, że grupa PHP wydała wersję PHP N, która zmienia sygnatury 30% funkcji. Teraz wyobraź sobie, że musisz napisać kod działający zarówno na PHP vN, jak i PHP v. {N-1} - ile by to było zabawy?

Teraz wyobraź sobie, że jesteś hosterem lub korporacyjnym menedżerem centrum danych - jaką zachętę miałbyś wspierać PHP vN, pod warunkiem, że po zmianie cały kod zostanie uszkodzony, a użytkownicy przyjdą do twojego biura z widłami i pochodniami?

Ponieważ PHP jest językiem bez żadnych specyfikacji.

I dosłownie każdy mógł dodać kilka funkcji i na początku nie było mowy o spójności. A więc bałagan.

Większość dobrych języków jest i dąży do zachowania spójności.

To tylko rzeczywistość stanu PHP. Jak wspomniał StasM, koszmarem byłoby próba zmiany takich rzeczy po fakcie. Wpłynęłoby to na zbyt wiele istniejącego kodu. Często PHP po prostu zastępuje funkcje i tworzy nowsze, lepsze funkcje, które są bardziej spójne, ale mogą zająć dużo czasu.

Myślę, że odnoszący sukcesy programiści PHP albo pamiętają określoną składnię, albo używają oprogramowania, które automatycznie mówi im składnię.

Głównym źródłem niespójności jest to, że wiele (większość?) Wbudowanych funkcji php jest tak naprawdę owijanych wokół jakiejś biblioteki C. Początkowe myślenie brzmiało: „Zawijam funkcję C xxxx, dlatego powinienem zachować tę samą kolejność parametrów”. Jeśli chodzi o pisanie funkcji „czystego php”, to myślenie zostało rozszerzone na „xxxx bierze plik i opcje, nowa funkcja przyjmuje nazwę pliku i opcje, więc sensowne jest, aby yyyy przyjmował te same parametry w tej samej kolejności.

Wielka wada polega na tym, że leżące u podstaw biblioteki C były bardzo niespójne na początku.

Powodem (a?) Była zgodność z poprzednimi wersjami PHP. Zamiast zmieniać nazwy funkcji, które mogłyby uszkodzić wiele aplikacji, funkcje pozostają. Jednak intuicyjnie należy brać pod uwagę spójne nazewnictwo funkcji dla nowych języków.

Muszę się z tobą nie zgodzić, że marnuje się czas na rozwój. Nauka PHP może potrwać dłużej, aby zrozumieć nazewnictwo niektórych funkcji, ale po opanowaniu (lub przynajmniej uświadomieniu sobie) staje się to problemem.

Kompatybilność> Spójność (przynajmniej dla PHP)