Która wersja implementacji wam się bardziej podoba?

private function delimiter(string $pattern): string
{
    foreach (self::$candidates as $candidate) {
        if (\strPos($pattern, $candidate) === false) {
            return $candidate;
        }
    }
    throw new DelimiterException();
}

vs

private function delimiter(string $pattern): string
{
    $availableDelimiters = \array_diff(self::$candidates, \str_split($pattern));
    if (empty($availableDelimiters)) {
        throw new DelimiterException();
    }
    return \current($availableDelimiters);
}

Wiem, że łatwiej pokazać różnice przez diff, ale jednak chyba lepiej jakbyś wkleił kod.

Dla kogoś kto nie zna PHP to pętla

żadne, drugie jest lepsze ale używasz backslashy czego ja nie cierpię widzieć w kodzie.

Czy w tej bibliotece w danym namespace używasz nazw funkcji które są takie same jak te wbudowane w PHP?
Czy masz może jakieś inne wyjaśnienie po co te brzydkie slashe?

Poza tym jakoś dziwne mi wygląda używanie self:: w prywatnej metodzie.

Jeśli self::$candidates nie jest statyczne, to raczej powinno być tam $this->candidates. Z kolei skoro $candidates może być statyczna, to czemu metoda jest prywatna i non-static?

Możliwe, że czegoś tu nie łapie, bo od dawna nie widziałem tak dziwnych konstrukcji.

W opcji drugiej - zwracasz też current($availableDelimiters), czy to oznacza że może tam być więcej elementów w tym arrayu? Bo w opcji pierwszej jawnie zwracasz pierwszy napotkany element. Czy w obu wersjach będzie to ten sam element?

Ja tam bym skłaniał się ku pierwszej wersji

axelbest napisał(a):

Czy w tej bibliotece w danym namespace używasz nazw funkcji które są takie same jak te wbudowane w PHP?
Czy masz może jakieś inne wyjaśnienie po co te brzydkie slashe?

Nic to nie ma wspólnego z pytanie z tematu.

Ale jeśli koniecznie chcesz zaspokoić swoją ciekawość, to calle z jawnym namespacem (czyli albo \strLen(), albo zaimportowane use function strLen;) wołają funkcję bezpośrednio, a kiedy używa się funkcji bez tego slasha, to wtedy to jest niejawne: funkcja może być albo w aktualnym namespace'ie albo w globalnym, i PHP każdorazowo robi checka. Różnica w performance jest widoczna w profilerze.

axelbest napisał(a):

Poza tym jakoś dziwne mi wygląda używanie self:: w prywatnej metodzie.

Jeśli self::$candidates nie jest statyczne, to raczej powinno być tam $this->candidates. Z kolei skoro $candidates może być statyczna, to czemu metoda jest prywatna i non-static?

Znowu to nie ma nic wspólnego z pytaniem.

Pole $candidates jest statyczne, bo jest stałe i nie potrzebuję tworzyć instancji array'a osobnego dla każdego instancji obiektu. Metoda nie jest statyczna bo nie ma powodu żeby była statyczna, nie możnaby jej wtedy użyć do polimorfizmu, interfejsu, nic. Nie mam nigdzie w kodzie funkcji statycznych.

axelbest napisał(a):

W opcji drugiej - zwracasz też current($availableDelimiters), czy to oznacza że może tam być więcej elementów w tym arrayu? Bo w opcji pierwszej jawnie zwracasz pierwszy napotkany element.

a return \current() to niby nie jest jawnie zwrócony pierwszy element?

axelbest napisał(a):

Czy w obu wersjach będzie to ten sam element?

No weź się zastanów, i sam sobie odpowiesz. Tak, w obu wersjach będzie ten sam wynik.

anonimowy napisał(a):

Dla kogoś kto nie zna PHP to pętla

nom, ja w PHP dawno już nie pisałem i pierwsza wersja jest dość straightforward - po prostu przejeżdżanie przez kandydatów i jak nie ma w nich patternu, to zwracamy kandydata (swoją drogą czy to nie powinno być odwrotnie).

a druga to jakaś magia (tzn. jakbym zajrzał do dokumentacji, to pewnie nie byłaby magia, ale mówię z perspektywy osoby, która już pozapominała, jak się programuje w PHP)

Zadałem pytanie, bo PHP jest znany z tego że wbudowane funkcje są często dużo wydajniejsze niż kod napisany w samym PHP, więc pomyślałem że może warto zamienić pętle na takie dwie funkcje wbudowane.

To skoro profiler Ci mówi wszystko to po co pytasz? Sprawdź profilerem co jest lepsze i tyle :)

axelbest napisał(a):

To skoro profiler Ci mówi wszystko to po co pytasz? Sprawdź profilerem co jest lepsze i tyle :)

Nie wiem po co Ci w ogóle odpowiadam, na razie nie dostarczyłeś nic wartościowego do tego tematu.

Bardzo bym poprosił żebyś się nie udzielał więcej w nim.

Nie myl dwóch pojęć. Pytasz nas o czytelność a mówisz coś o wydajności. Rzadko kiedy wydajność aplikacji jest problemem bo problemem jest baza.
Jeśli to jest biblioteka dla innych np. to fajnie żeby była szybka

Używanie statycznych atrybutów klasy, ma sens jak się planuje je np. globalnie modyfikować dla wszystkich instancji.
Takie użycie statycznej tablicy, to jest przerost formy nad treścią.

Nie wnikając w wydajność, druga podoba mi się bardziej. Łatwo zauważyć w niej przyczynę rzucania wyjątku i return jest przewidywalnie na końcu.

full_stock napisał(a):

Nie wnikając w wydajność, druga podoba mi się bardziej. Łatwo zauważyć w niej przyczynę rzucania wyjątku i return jest przewidywalnie na końcu.

Dzięki.

omenomn2 napisał(a):

Używanie statycznych atrybutów klasy, ma sens jak się planuje je np. globalnie modyfikować dla wszystkich instancji.
Takie użycie statycznej tablicy, to jest przerost formy nad treścią.

W sumie tak. Dzięki za odpowiedź.

Nie znam PHP, ale pierwsza podoba mi się bardziej, ze względy na early return (performance). Obydwie nie podobają mi się ze względu na wyjątek z metody prywatnej, tu jednak bez szerszego kontekstu trudno ocenić czy ten wyjątek się broni, czy jest exception driven development. Gdzie jest obsługa tego wyjątku? W metodzie publicznej czy obsługuje ten, kto woła metodę publiczną?

Jak testujesz te metody? Domyślam się, że w ramach testów jakiejś metody publicznej, ale tu ciekawe jestem kto obsługuje wyjątek.

Z ciekawości wrzuciłem do CzataGPT i wypluł coś co wygląda jak 3-cia droga z bieda optionalem, ale bez wyjątku. Wygląda jak dobry punkt wyjścia do wywalenia wyjątku i self::candidates.

private function delimiter(string $pattern): array
{
    $availableDelimiters = array_filter(self::$candidates, function($candidate) use ($pattern) {
        return strpos($pattern, $candidate) === false;
    });

    if (empty($availableDelimiters)) {
        return ['isPresent' => false];
    }

    return ['isPresent' => true, 'value' => current($availableDelimiters)];
}

yarel napisał(a):

Nie znam PHP, ale pierwsza podoba mi się bardziej, ze względy na early return (performance). Obydwie nie podobają mi się ze względu na wyjątek z metody prywatnej, tu jednak bez szerszego kontekstu trudno ocenić czy ten wyjątek się broni, czy jest exception driven development. Gdzie jest obsługa tego wyjątku? W metodzie publicznej czy obsługuje ten, kto woła metodę publiczną?

Niby early return, ale to jest O(n*m), bo pętla est ma O(n) a strPos() ma O(m). Podobną ma array_diff().

Wyjątek jest interfejsem tej klasy, tzn on ma być rzucony. Co za różnica czy z prywatnej funkcji czy nie? ;| z resztą nie tego dotyczy wątek.

Jak testujesz te metody? Domyślam się, że w ramach testów jakiejś metody publicznej, ale tu ciekawe jestem kto obsługuje wyjątek.

Zapewniam Cię że są bardzo dobrze przetestowane.

Poza tym, nie tego w ogóle dotyczy pytanie.

Z ciekawości wrzuciłem do CzataGPT i wypluł coś co wygląda jak 3-cia droga z bieda optionalem, ale bez wyjątku. Wygląda jak dobry punkt wyjścia do wywalenia wyjątku i self::candidates.

private function delimiter(string $pattern): array
{
    $availableDelimiters = array_filter(self::$candidates, function($candidate) use ($pattern) {
        return strpos($pattern, $candidate) === false;
    });

    if (empty($availableDelimiters)) {
        return ['isPresent' => false];
    }

    return ['isPresent' => true, 'value' => current($availableDelimiters)];
}

Myślałem o tym, ale tutaj jest dodatkowa funkcja anonimowa, a w php takie funkcje są performance'owo drogie. Po drugie array_filter() przejdzie wszystkie przypadki, nawet jeśli dałoby się zwrócić pierwszy early returnem. Po trzecie, ja chcę mieć prosty kod. Zwrócenie tablicy ze zmienną ilością elementów, z magicznymi nazwami, nie jest wcale prostsze. Skomplikuje to design.