Jak wszystkiego trzeba używać z umiarem, nikt nie będzie strzelał przeca za użycie jednego wyrażenia zamiast std. funkcji.
Ale jak już ktoś odpali reg_exp w pętlli np. 10k elementów zamiast str_replace to już przesada.

Także jestem ciekawy dlaczego należy ich unikać. Jezeli ktos nie potrafi ich przeczytać to juz jego wina/problem. Ld tego są takie strony jak np. Regex101.

Konkrety Panie... Jak masz potrzebę odpalenia 10k preg_* lub str_* to czym przedkładasz jedno nad drugie? Mam dziwne wrażenie że macie jakieś złe wspomnienia z eregi, które dawno wyleciało i było czym innym.

Tu nie chodzi tylko o to czy ktoś umie czy nie, tylko też o czas jaki to zajmuje, wyłapywanie błędów i tak dalej. Wyrażenia regularne są nieczytelne i nie zmieni tego nawet Twoja doskonała ich znajomość Skomplikowanych wzorców się nie czyta jak bajki na dobranoc.

Czyli nie masz żadnego argumentu, poza "bo tak, bo ja nie ogarniam". Równie dobrze mógłbyś napisać że ORM, lub inne metody pomocnicze w budowaniu zapytań do bazy są lepsze, bo sam język SQL jest za trudny.

W przypadku gdy jedynym argumentem jest nie czytelność skomplikowanych wzorców to smutne, ponieważ skomplikowane wzorce z definicji są trudne w czytaniu. Np. prosta walidacja czy mamy do czynienia z kodem pocztowym:

[PHP] pobierz, plaintext 
^([0-9]{2})-([0-9]{3})$
[PHP] pobierz, plaintext 

Co jest w tym trudnego do czytania? A zrób to jakimiś funkcjami php. Chętnie porównam wyniki w pętli 1000


edit:

oczywiście, że przeważnie str_replace itp. są lepszym rozwiązaniem. Jednak tam gdzie potrzeba skomplikowanych regex (parsowanie kodu html - łatwiej regex niż jakieś parsery html - oczywiście czasami, nie zawsze) - po prostu po to ktoś je wymyślił. Mają ułatwiać

[PHP] pobierz, plaintext 
list($pre, $post) = explode('-', '12-200');
if(is_numeric($pre) && strlen($pre) == 2 && is_numeric($post) && strlen($post) == 3)
{
    die('good');
}
[PHP] pobierz, plaintext 

Taki sam argument jest za stosowaniem refaktoryzacji, "bo bez refaktoryzacji ja nie ogarniam". Programy są pisane tak jak są po to, żeby wszyscy ogarniali.

Wyrażenia regularne to inny język, którego treść jest w stringu. Jest to język, który się w większości implementacji fatalnie formatuje. Wyrażenia regularne mają więcej haczyków w implementacjach w różnych językach niż DOM w IE. Do tego większość ludzi pisze wyrażenia regularne jednocześnie nieczytelnie i niewydajnie. Niektórzy nawet sądzą, że *generowanie* wyrażenia regularnego w kodzie to świetny pomysł.

http://php.net/is_numeric

Czyli Twój kod da się oszukać :P

@solificati - pewnie że tak.

Nie napisałem że to jest ideał Pisane na szybko.
Oczywiście że w tym i wielu innych przypadkach lepiej użyć reg_exp.

Niech każdy używa czego chce Ja czasami z lenistwa wolę regexp '(slowo|slowo2)' niż bawić się w coś innego. Kontekst jest ważny.

Jak tam Wasze poniedziałki?

Ooo, ten wątek jeszcze żyje? Nieźle.
Pamiętam jak dziś kiedy powstawał

Mi łatwiej napisać str_replace

W nocy po żone musiałem pojechać po koncercie, także masakra a jeszcze po pracy meet.js się szykuje.


btw:

właśnie pierwszy raz w życiu użyłem Trait. Nawet przydatne, co o tym mechanizmie sądzicie?

Ostatnio z uporem maniaka próbowałem w kilku miejscach zastosować traitsy i chyba zrobiłem to dobrze, ale
skoro mają one zastępować szablony z C++ bądź naokoło wdrażać dziedziczenie po wielu klasach którego nie ma w PHP to dlaczego nie mogę zmienić typów argumentów w poszczególnych metodach. W takim \ArrayAccess na przykład by się to przydało.

Kolego wykrzyknik-gwiazdka-wykrzyknik, na każdym kroku każdego pojeżdżasz, zastanawiam się po co. Akurat tak się składa, że znam wyrażenia regularne BARDZO dobrze, zresztą nawet na tym forum pomagałem wielokrotnie z regexem. Po raz któryś już pokazujesz, że nigdy nie pracowałeś nad profesjonalnymi projektami, tworzonymi w grupie programistów. W poważnych projektach kod pisze się tak, żeby był czytelny dla pozostałych programistów. I to nie oznacza, że oni są kiepscy i nie potrafią tego odczytać. Wręcz przeciwnie. To oznacza, że oni mają do roboty 100 innych rzeczy i szkoda ich czasu na analizę kodu, który można było napisać prościej. Tylko że tak jak napisałem wcześniej, z wyrażeniami regularnymi na ten moment zwykle nie ma lepszej alternatywy.

No jeśli kod pocztowy to najtrudniejszy przypadek jaki możesz sobie wyobrazić, to się nie dziwię, że tak podchodzisz do tematu ;)

Nie, to jest bardzo prosty przypadek, który pokazuje jak regex jest przydatny. Ciężko to zrobić inaczej - czyściej czy krócej.

Trudny przypadek to idealne parsowanie adresu email:

http://www.regular-expressions.info/email.html

Nawet nie idealne ale zwykłe [a-z0-9]@[a-z0-9].[a-z] już jest trudno zastąpić czym innym pod względem czytelności. A czym bardziej skomplikowany regex na to tym bardziej skomplikowany będzie kod. W końcu zrobi się odzielna klasa - odzielna biblioteka i w końcu cały bundle

Podany przez Ciebie wzorzec zaakceptuje nawet np. 7@7@x, więc chyba nie za bardzo. Ja lubię czasem krok po kroku analizować string, nie upychać tego na siłę do jednej instrukcji. Chociaż przyznam się, że zbyt często kończę tworząc jeden wielki wzorzec, no ale czytelne to to potem nie jest.

Operatory parserów (parser combinators) albo translatory z gramatyk bezkontekstowych. To dobre rozwiązania do większych problemów.

Co do kodu pocztowego, kiedyś słyszałem taki rule of thumb, że jeśli wywołanie wyrażenia regularnego idzie zamknąć w funkcji to jest ok. Jeśli napotkam wywołanie is-zip-code, to nie muszę się przejmować wyrażeniem w środku, tylko wywołać funkcję. Jak chcę refaktoryzować, zmieniać, debugować to i tak muszę pobrudzić ręcę. Ważne jest też ten fakt o wywołaniu - chodzi o to, żeby nie wyciekały instancje matchera i nie było korzystania z grup poza funkcją. Grupy nazwane częściowo rozwiązują ten problem, ale najlepiej żeby zwrócić stosowną strukturę, bo dociekanie co oznacza null albo false w różnych polach gdy wyrażenie się nie dopasowało jest straszne.

@SmokAnalog - właśnie czekałem na ten moment w którym będziesz pisał mi, albo Fortiemu w jakich to nieprofesjonalnych grupach pracujemy lub pracowaliśmy. Pytanie było proste, nie odpowiedziałeś, bo argument "kod jest mało czytelny" nie jest argumentem, rzecz względna, tak samo jak pisanie czystego SQL na 50 linijek... Można to ładnie formatować, tylko po co, są proste reguły które się nie zmieniają, już nie mówiąc o kolorowaniu całości przez IDE które pomaga jakby ktoś się gubił w nawiasach... język jak każdy inny.

Zapytać na forum php dlaczego należy czegoś unikać... odpowiedź, bo się gubimy w krzaczkach... boskie...A liczyłem na coś choćby... wyciek pamięci w preg_replace_callback... ale nie, krzaczki i nawiasy dziwnie stoją i nie ma czasu ich ogarniać.

troche nie ogarniam dyskusji i cisniecia SmokAnalog na te regexy... to powinno byc prosze niz czytanie bajki na dobranoc bo podstawa wyrazen jest logika. jesli komus sprawiaja trudnosc to odnosze wrazenie ze z mysleniem tez moze miec taki problem. to nie jest jakis tam wzorzec projektowy tylko proste wyrazenie opierajace sie o podstawy matematyki wiec wtf? ale to oczywiscie moje osobiste upodobania regexa nad inne funkcje do mielenia stringow. kto co lubi.

@!*! to juz chyba druga dyskusja w ciagu kilku ostatnich dni gdzie Smoku nie potrafi odpowiedziec na proste pytanie. olej bo szkoda nerwow.

@Pyton_000, poniedzialek super. 8 godzin ciecia jakis templatow zeby leciec do klienta na 18:30... takze na poczatek tygodnia po l4 14 godzin pracy lacznie z dojazdami


nie ma lekko

Ja zauważyłem że Smok zwyczajnie próbuje każdemu wmówić że to On ma racje...

Zdajesz się sugerować, że w pliku .php masz stringa z zapytaniem sql.

Nie macie przyjemniejszych tematów na Poniedziałek zamiast rzucać się do gardeł? Takie rzeczy to w piątek, bo przynajmniej można się uchlać

Bo wasze argumenty pokazują jasno, że nie mieliście do czynienia z poważnymi problemami programistycznymi. To jest niestety jeden z większych paradoksów na tym świecie, że świeżakowi coś się wydaje trudne, średnio ogarniętemu proste, a ogarniętemu znowu trudne. Wy jesteście w środku tej skali i po prostu nie natrafiliście jeszcze na problemy, gdzie regex nie jest idealnym rozwiązaniem. Wydaje Wam się, że to ja czegoś nie rozumiem, że Wy mnie czegoś uczycie. Ja nic do tego nie mam, kiedyś też mi się wydawało, że umiem więcej niż umiem. Możemy porozmawiać o projektach nad którymi pracowaliśmy i ile czasu programujemy.

tzm, na jakie pytanie nie odpowiedziałem?

a Ty do ktorej grupy ogarnietych sie zaliczasz?

1. pytali chlopaki dlaczego regex jest gorszy od Twoich rozwiazan. !*! juz wyraznie podsumowal ta dyskusje.

2. postep technologiczny komputerow. 3 osoby, przez 10 postow o cos Cie pytaly, a Ty zamiast odpowiedzi wciskales swoje prawdy. tutaj jest to samo jak z kolei zauwazyl Posio.

x: ktora godzina?
Y: zobacz jaki mam fajny zegarek
x: ale ja chce wiedziec ktora jest godzina
Y: ale to elektroniczny zegarek

i tak do porzygu.

spadam, czesc

No jakbyście czytali ze zrozumieniem to byście może jednak znaleźli odpowiedzi. Napisałem wyraźnie, że REGEX JEST NIECZYTELNY I TRUDNY DO SZYBKIEJ I BEZBŁĘDNEJ ANALIZY. Teraz widać?

EDIT Do której ja się grupy zaliczam? Do ogarniętej, bo po prostu od wielu lat pracuję jako programista. Chcąc nie chcąc mam styczność z tym na co dzień.

równie dobrze mogę napisać:
REGEX JEST CZYTELNY I ŁATWY DO SZYBKIEJ I BEZBŁĘDNEJ ANALIZY. Teraz widać?
nie ? nie widać ?
Przykład Panie, bo tak to można całą wieczność dyskutować

Ostatnio miałem do czynienia z pluginem, który parsował stringa strpos-em. String wyglądał mniej więcej tak: {PLUGIN}kategoria/13,jakisParametr=1,jakisParametr=0,jakisParametr=1,jakisParametr=0{/PLUGIN}
Tutaj regex pasuje jak ulał. Podstawiamy wyrażenie i pobieramy dane do ładnych zmiennych za pomocą list(). Proste i eleganckie. Ale nie, ktoś wziął się za to strposem...

Turson, no pewnie - to jest piękny i prościutki przykład do używania regexa. Ja bardzo lubię funkcję preg_replace_callback do parsowania wszelkich shortcode'ów i innych kontekstowo analizowanych tekstów.

Ale antyprzykładem jest przede wszystkim HTML, XML oraz praktycznie każdy tekst pisany przez człowieka w formie zdań, bo wtedy musimy zakładać bardzo wiele możliwości - mnogość białych znaków, nowych linii itd. Taki wzorzec jest potem po prostu brzydki, długi i łatwo w nim o pomyłki. Poza tym, co zresztą zrobił jeden z kolegów wyżej, bardzo często spotykanym i trudnym do wyłapania błędem jest podawanie wymogu znaku kropki jako ".", co potem kończy się dość tragicznie.

Nie wiem jakie wrażenie odnieśliście po moich wcześniejszych wypowiedziach, ale prawda jest taka, że ja regexy bardzo lubię, ale nie lubię, gdy są nadużywane lub pisane niechlujnie - gdy np. są zbyt tolerancyjne (jak wzorzec e-maila kolegi) lub za mało (np. odrzucające dwie spacje obok siebie w tekście pisanym).

Swoją drogą, metoda na strpos jest jeszcze mniej czytelna niż regex, jeśli się używa tego do czegoś więcej niż sprawdzanie czy ciąg znaków jest obecny czy nie. Do bardziej skomplikowanych operacji na tekście lubię robić to krok po kroku, formatując najpierw tekst do późniejszego przetestowania lub wyłapania czegoś.

Wasza akademicka dyskusja o wyrażeniach regularnych powinna skończyć się dawno temu. Przecież dobre praktyki programowania mówią jasno, że taki nieczytelny dla wszystkich kawałek kodu należy zamienić czytelnym czyli na przykład stałą lub zmienną (zależy od kontekstu) o nazwie, która sama się dokumentuje:

[PHP] pobierz, plaintext 
$postCodePattern = '^([0-9]{2})-([0-9]{3})$';
$blaBlaCośTuSięDzieje = preg_match($postCodePattern, $input);
[PHP] pobierz, plaintext 

Wątek? Chłopie, to czy Ty jeszcze żyjesz? Nieźle Tak dawnooooooo Cie tu nie było

Skoro jestesmy przy wyrażeniach, to taka mała prywata z ogólnie powszechną prawdą:
http://jokes.nospor.pl/view/id/52/

A jakoś tak z nudów zajrzałem będąc ciekawym co u Was słychać

Hahaha

@Nospor - uważaj z tymi cytatami, bo zaraz Cię tu wyzwą, że ich po prostu nie umiesz

A bo to ja napisalem? Ja tylko cytuje Co nie zmienia faktu, ze tak z 50% prawdy w tym jest. Nie raz na forum widzialem, jak ludzie walczyli z wyrazeniami, a wystarczylo uzyc zwyklej funkcji php do rozbicia tekstu.
Oczywiscie zeby nie bylo, wyrazenia są jak najbardziej potrzebne, ale nei zawsze, i o tym traktuje ten cytat

Nigdy nie interesując się szczególnie innymi użytkownikami forum nawet po tylu latach skrawkiem umysłu kojarzę, że teraz się zajmujesz Javą?

Ale mam dobrą pamięć, tran robi swoje.

Owszem, już od kilku lat żyję w świecie JVM.

Jakiś język poza Javą na JVM też?

(Ukryte pytanie: Scala czy Clojure)

Mike - jak wygląda Wasza relacja z Javą? Lubicie się? Jak wygląda praca developera javowego w porównaniu do pehapowca?

Lepiej pod prawie każdym względem

Czy ktoś się spotkał z czymś takim, że FB przy wklejaniu linku do statusu nie chce go przemielić i wstawić jako box?
Ostatnio dla 2 linków z mojego bloga FB odmawia posłuszeństwa

Choćby ten: http://blog.piotrows.pl/laravel-5-czysta-instalacja/

Próbowałem na 2 kompach ale dupa, a niestety nigdzie nie da się wysypać jakiegoś błędu czy coś

a gdzie masz open grapha? nie ma z czego czytac.

Ok, ale jak wstawiam inne linki z bloga to już parsuje dobrze, więc to nie jest raczej wina OG

Przypomnij mi funkcje artisana w laravel?

Khee??

edit: lool widze... nvm

sprobuj dodac tego open grapha i zobacz co sie stanie, 5 minut roboty a bedziesz wiedzial czy pomoze. facebook jak nie ma open grapha to leci na czuja... widocznie strona nie ma kontekstu, haha joke

No niestety nic nie dało Jeszcze jakieś pomysły ?

Z grubsza tylko źródła przejrzałem i nic się nie rzuca w oczy także, rozkładam ręce niestety.

ale wiesz, liczą się chęci

Wyczyść cache tak jak tu opisują: http://www.marketingyourpurpose.com/facebo...ew-not-working/

Może ktoś widział jakiś dobry uchwyt do Lumi? Może być też uniwersalny.

do auta czy taki na biurko powiedzmy stojak?


co to facebooka jeszcze.. faktycznie z tym cache jest jak Smok pisze, facebook sobie taki mini cache robi do tego wiec jak raz nie zadziala to potem nie potestujesz bez resetu, dzis to przerabialem... za pierwszym razem nie dzialalo wiec moze jednak OG pomogl a nie widac?