Witam,

Nawiązując do tego wątku: http://stackoverflow.com/questions/3525507...pes-good-or-bad

Co myślicie na temat zwracania typu mixed przez funkcje/metody. Jakie macie podejście do sprawy, przy niepowodzeniu FALSE czy rzucanie wyjątku.
Myślę że warto podyskutować, może rozwinąć się ciekawy wątek.

Mieszanie typu zmiennej (dotyczy również typu zwracanej wartości przez funkcje) jest bardzo, bardzo złą praktyką. Zmniejsza czytelność kodu i zwiększa jego podatność na błędy. Natomiast zwracanie null/false w celu poinformowania o błędzie to już czysty sadyzm ze strony dewelopera - właściwie w każdym kodzie, w którym stosuje się takie coś istnieją dziesiątki miejsc, gdzie nie sprawdzono czy aby przypadkiem nie wystąpił błąd.

Czyli wg Twojego rozumowania funkcja powinna mieć z góry ustalony typ dla każdej z danych wejściowych.

1. Argument ma niewłaściwy typ, rzucany jest wyjątek.
2. Nie może być zwrócona wartość o typie danych jak z założenia - rzucany jest wyjątek.

Nikt inny się nie udziela to pewnie uważają tak samo ;P

Pseudotyp mixed zwykło się umieszczać w komentarzach funkcji/metod w przypadku jeśli dany kod powinien normalnie zwrócić jakieś dane (tablicę/obiekt) ale może również zwrócić (tylko w przypadku błędu) false, null, -1 (wszystko, co spełni warunek skróconego zapisu):

[PHP] pobierz, plaintext 
if(cos_tam())
{
  // ok
}
else
{
  // coś poszło nie tak
}
[PHP] pobierz, plaintext 

ot cała filozofia. Zwracanie false lub null przez funkcje/metody wydaje się być pewnym niepisanym standardem php. Wyjątek można rzucić później (w podanym warunku sprawdzającym). Oczywiście wyjątki są bardzo dobrym rozwiązaniem, bezpieczniejszym, ponieważ nie ma potrzeby przewidywania różnych sytuacji w zależności od danych wejściowych.

PHP jest językiem z dynamicznym typowaniem zmiennych, jednak jest to cecha wygodna tylko przy pisaniu "na szybko/śmieciowego" kodu. Każda zmienna powinna przechowywać wyłącznie jeden typ danych, bądź ewentualnie null, w przypadku gdy "nie ma wartości". Wyjątkiem będzie sytuacja, gdzie potrzebujemy uzyskać kilka różnych sygnatur dla danej metody, czyli gdy ją przeciążamy. Wtedy jednak należy jak najszybciej doprowadzić typy zmiennych do ich docelowych typów i dopiero brać się za wykonywanie właściwego kodu metody.

A do zgłoszenia każdego błędu/nieprawidłowości mamy wyjątki.

Jeżeli twoja funkcja w zalożeniu ma zwrócić tablicę | string | int to w przypadku blędu może zwrócić pustą tablicę | string | 0.

[PHP] pobierz, plaintext 
class user {
 
    protected $_insert_id;
    protected $_affected_rows;
 
    public function save()
    {
        // Validacja danych wejsciowych 
        if($valid)
        {
            return false;
        }
 
        // zapis / update do bazy
        if(zapis)
        {
            $this->_insert_id = (metoda zwraca id)
            return true;
        }
 
        $this->_afected_rows = (metoda zwraca ilosc rekordów na ktore zadziałało zapytanie);
        return true;
    }
 
    public function insert_id()
    {
        return $this->_insert_id;
    }
 
    public function affected_rows()
    {
        return $this->_affected_rows();
    }
}
[PHP] pobierz, plaintext 

Taki mały przykładzik jak trzymać się typu zwracanego w modelu. Wyjątki rzucają metody odpowiedzialne za obslugę bazy danych.

W takim przypadku nie da się przewidzieć, jaki typ danych zwróci metoda, bo przecież można zażądać ID użytkownika (int) albo jego loginu (string).
Wtedy pozostaje walidować zwróconą wartość w zależności od kontekstu użycia metody.

Ktoś zna lepsze rozwiązanie?
Zakładamy, że tych indeksów jest 200 i tworzenie dla każdego oddzielnej metody jest przerostem formy nad treścią.

Lepszym rozwiązaniem jest nie tworzenie czegoś takiego.. Jeżeli masz użytkowników, to niech w aplikacji będą oni widoczni jako... użytkownicy, tj. obiekty typu Użytkownik.

Jednak co do samego przypadku. Tak, mogą zdarzyć się kolekcje danych o różnym typie, ale w miarę możliwości powinno się ich unikać.