Sugestia nazwania metody?

Jak mogłaby nazywać się metoda zwracająca tekst jako integer? (* możesz oddać maksymalnie 3 głosy)
`group('[0-9]')->parseInt()`
26%
26% [6]
`group('[0-9]')->asInt()`
30%
30% [7]
`group('[0-9]')->int()`
4%
4% [1]
`group('[0-9]')->toInt()`
39%
39% [9]
Odpowiedz Nowy wątek
2019-09-03 13:20
0

Piszą znowu w sprawie T-Regx'a. Czasem pisze się regexp-y/grupy - np takie: [0-9]{2,}, która oczywiście musi się składać z cyfr i wtedy lepiej operować na zmiennych typu int, a nie string. Metoda już istnieje, ale nie jestem przekonany co do tego czy powinna się nazywać tak jak teraz. Jakie jest wasze zdanie?


edytowany 1x, ostatnio: TomRiddle, 2019-09-03 16:42

Pozostało 580 znaków

2019-09-03 17:35
0
Silv napisał(a):

Rozumiem więc, że chcesz "poprawić" to zachowanie? W takim razie myślę, że T-Regex nie powinien tego robić,

$phpWay = (int) $details->text();   // domyślne
$tRegxWay = $details->parseInt();   // normalne, imo

Ależ proszę :)

tylko oddzielna biblioteka (czy tam co jest w PHP mniejszego od biblioteki).

Ale to jest tylko jedna funkcja, a osłania przed bugami jak szalona :)


edytowany 3x, ostatnio: TomRiddle, 2019-09-03 17:38

Pozostało 580 znaków

2019-09-03 17:40
0

Nadal pozostaję przy swoim zdaniu. Nie jest odpowiedzialnością biblioteki wyrażeń regularnych konwersja między typami. Powinna to być odpowiedzialność języka lub, w przypadku PHP, może innej biblioteki. Jeśli T-Regex byłaby biblioteką zarówno wyrażeń regularnych, jak i konwersji typów, to zgodziłbym się z Tobą, że może taka metoda jak toInt się w niej znaleźć. Gdy zaś nie jest, możesz również napisać coś jak pod-bibliotekę, czy też zewnętrzną bibliotekę "zaprzyjaźnioną" z tą (nie znam się na PHP, tak strzelam, że tak się robi).


edytowany 1x, ostatnio: Silv, 2019-09-03 17:40

Pozostało 580 znaków

2019-09-03 17:42
0
Silv napisał(a):

Nadal pozostaję przy swoim zdaniu. Nie jest odpowiedzialnością biblioteki wyrażeń regularnych konwersja między typami. Powinna to być odpowiedzialność języka lub, w przypadku PHP, może innej biblioteki. Jeśli T-Regex byłaby biblioteką zarówno wyrażeń regularnych, jak i konwersji typów, to zgodziłbym się z Tobą, że może taka metoda jak toInt się w niej znaleźć.

Dobrze więc. Wyobraźmy sobie dwa wyrażenia regularne:

  • \w+ - łapie litery, cyfry i _
  • \d+ - łapie tylko cyfry

Chciałbym mieć funkcję, która pozwoli mi "wyciągnąć" zmienną int z grupy \d+, a dla tego co jest w grupie \w+ rzuci wyjątek, jako oznaka niepoprawnego użycia metody.

Jakbyś nazwał taką funkcję? Dopiszę Twoją propozycję do ankiety.

Gdy zaś nie jest, możesz również napisać coś jak pod-bibliotekę, czy też zewnętrzną bibliotekę "zaprzyjaźnioną" z tą (nie znam się na PHP, tak strzelam, że tak się robi).

Biblioteka na jedną funkcję?


edytowany 1x, ostatnio: TomRiddle, 2019-09-03 17:45

Pozostało 580 znaków

2019-09-03 17:43
0

Jeśli musisz poprawiać styl PHP – nie widzę innej drogi. Ale nie jest to droga zła, moim zdaniem – najwazniejsze, by przekonać użytkowników, że stosowanie tej dodatkowej biblioteki ma sens w T-Regexie. Jeśli nie potrafiłbyś przekonać – to czy ma sens umieszczanie takiej metody bezpośrednio w T-Regexie?


Zerknij na moją odpowiedź wyżej, edytowałem ją. - TomRiddle 2019-09-03 17:46
Zobaczę. - Silv 2019-09-05 01:24

Pozostało 580 znaków

2019-09-03 17:47
0
Silv napisał(a):

najwazniejsze, by przekonać użytkowników, że stosowanie tej dodatkowej biblioteki ma sens w T-Regexie. Jeśli nie potrafiłbyś przekonać – to czy ma sens umieszczanie takiej metody bezpośrednio w T-Regexie?

Średni argument. Korzystam z wielu elementów np Laravela, Angulara, Reacta czy innych, ale gdyby nie były wbudowane to raczej nie ściągałbym dodatkowych rozwiązań właśnie pod to. Myślę że wielu użytkowników się zgodzi.


Pozostało 580 znaków

2019-09-05 02:01
0

Zgodzę się w tym z Tobą, że to, co pisałeś, może tak wyglądać od strony użytkownika. Aż tak dobrze nie znam się na tworzeniu oprogramowania, by mówić Ci, który wariant jest lepszy. Jedynie sugerowałbym wybór innego rozwiązania niż wprowadzanie tej metody bezpośrednio do biblioteki. Nie jestem pewien, co sam bym zrobił na Twoim miejscu. Może spróbowałbym jakoś ominąć tę potrzebę konwersji (żeby jej nie czuć / nie mieć)?

Co do edycji posta. Nie mam dużego doświadczenia w używaniu bibliotek/języków do wyrażeń regularnych. Z tego, co myślę, to gdybym sam projektował publiczne API do takiej biblioteki, zwracałbym po prostu zawsze string. Odpowiedzialnością zewnętrznej funkcji byłoby, żeby parsować ten string. Domyślam się, jak to dla Ciebie brzmi; czasem jak patrzę na przykłady konwersji z języków silnie typowanych, to mam uczucie, że to tak nie powinno wyglądać, że odpowiedzialność za jakąś część kodu nie powininna być tak poszatkowana na odpowiedzialności poszczególnych klas. Ale jak się zastanawiam niezależnie od języka, to wychodzi mi, że tak powinno być. Że odpowiedzialności należy dzielić jak najdrobniej się da. To znaczy: w kodzie funkcji możesz parsować wynik jak chcesz, i zwracać int; jedynie ta funkcjonalność nie powinna być wystawiona w publicznym API.


edytowany 10x, ostatnio: Silv, 2019-09-05 02:05

Pozostało 580 znaków

2019-09-06 11:52
0
Silv napisał(a):

To znaczy: w kodzie funkcji możesz parsować wynik jak chcesz, i zwracać int; jedynie ta funkcjonalność nie powinna być wystawiona w publicznym API.

POLA.

Myślę że funkcja powinna zostać.


Pozostało 580 znaków

2019-09-06 14:32
0

@TomRiddle: niech zostanie, w końcu to Twoja biblioteka. :) Ja, być może, mylę się – ale na razie nie znam argumentów, które by to potwierdzały.

Rozumiem, że przez "POLA" masz na myśli https://en.wikipedia.org/wiki/Principle_of_least_astonishment. Nie widzę tutaj jej zastosowania. Dla mnie użytkownicy mogą oczekiwać zarówno string na wyjściu, jak i int.


Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0