Sugestia nazwania metody?

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?

2

int() ... nieeee. Gdyby nie ikonki w podpowiedziach IDE nie wiedziałbym czy to jest jakieś publiczne pole czy metoda :D

2

a może toInt

0
abrakadaber napisał(a):

a może toInt

Dodałem odpowiedź toInt(). Można oddać głos

0

Nie bardzo rozumiem, jak miałoby wyglądać "operowanie na zmiennych typu int" w tym przypadku?

1
Silv napisał(a):

Nie bardzo rozumiem, jak miałoby wyglądać operowanie na zmiennych typu int w tym przypadku?

Dokumentacja: https://t-regx.com/docs/match-details#integers

$text = "Key:pairs are as follows Foo:123 Bar:456";
$pattern = ;

pattern('(\w{3}):(\d{3})')->match($text)->first(function (Match $details) {
  $key = $details->group(1)->text();
  $value = $details->group(2)->asInt();   // or parseInt(), toInt();

  var_dump($key);    // string 'Foo';
  var_dump($value);  // int 123;
});
0

OK, chyba rozumiem, ale nie widzę jeszcze w tym kodzie przewagi int nad string.

0
Silv napisał(a):

OK, chyba rozumiem, ale nie widzę jeszcze w tym kodzie przewagi int nad string.

Myślę że gdybyś miał np \w{3}:\w{3} i dopasował to do tekstu Foo:Bar, i chciał użyć Bar jako int, to T-Regx rzuci NumberFormatException (że Bar to nie jest int). Spójność danych.

0

Ale czy to wtedy byłaby kwestia T-Regexa, czy też ogólnie PHP? Moim zdaniem to PHP powinien posiadać coś na kształt klasy string_utils/int_utils, w której to klasie byłoby toInt (czy inna nazwa).

0
Silv napisał(a):

Ale czy to wtedy byłaby kwestia T-Regexa, czy też ogólnie PHP? Moim zdaniem to PHP powinien posiadać coś na kształt klasy string_utils/int_utils, w której to klasie byłoby toInt (czy inna nazwa).

PHP spróbuje każdego stringa zamienić na int, nawet "1e3" na 1000 albo "010" na 8 (ósemkowy). Również " 1" to jest 1 w PHP.

0

Rozumiem więc, że chcesz "poprawić" to zachowanie? W takim razie myślę, że T-Regex nie powinien tego robić, tylko oddzielna biblioteka (czy tam co jest w PHP mniejszego od biblioteki).

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 :)

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).

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ę?

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?

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.

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.

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ć.

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.

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