Prepared Patterns - coś jak Prepared Statements w SQL - pytanie o API

Jak niektórzy wiedzą, piszę sobie bibliotekę T-Regx, i czasem utykam i mam pytanie. Otóż jakieś pół roku temu napisałem tam Prepared Patterns - czyli sposób składania wyrażeń regularnych z niebezpiecznych danych (np $_GET) - coś jak prepared statements w SQL właśnie.

Miałem 2 pomysły na strategie, nie mogłem zdecydować się który jest czytelniejszy więc zaimplementowałem oba, ale teraz wracam i zastanawiam się czy one na pewno mają sens, oto przykłady kodu do sklejania wyrażeń:

Strategia #1:

$name = $_GET['name'];
$food = $_GET['food'];

Pattern::prepare(["(My|Our) dog's name is ", [$name], ' (and|or) he likes', [$food], '!']);

Strategia #2:

$name = $_GET['name'];
$food = $_GET['food'];

Pattern::inject("(My|Our) dog's name is @name (and|or) he likes @food!', [
    'name' => $name,
    'food' => $food
]);

oba te zapisy wyżej znaczą "mniej więcej" w uproszczeniu to:

"/(My|Our) dog's name is " . preg_quote($input, "/") . ' (and|or) he likes' . preg_quote($food, "/") . "!/"

(w uproszczeniu bo PreparedPatterns robią jeszcze więcej safe-checków niż preg_quote).

Tak czy tak, który z tych zapisów - strategia 1 czy strategia 2 wam się bardziej podoba - jest czytelna? Bo strategii 1 nie zobaczycie w żadnym API do prepared patterns w SQL.

TomRiddle napisał(a):

strategia 1 czy strategia 2 wam się bardziej podoba - jest czytelna?

Żadna mi sie nie podoba, bo przecież php ssie, no nie? ;)

czysteskarpety napisał(a):

TomRiddle napisał(a):

strategia 1 czy strategia 2 wam się bardziej podoba - jest czytelna?

Żadna mi sie nie podoba, bo przecież php ssie, no nie? ;)

No tak.

Ale nie wszystko napisane w PHP ssie. Wyobraź sobie że nie ma $ przed zmiennymi i tada, masz JavaScript.

inject bardziej przypomina sprintf (które lubię z racji swojej czytelności), stąd mój głos poszedł w tę stronę :-)