N-am zis asta. E doar un side-effect interesant si foarte util. De exemplu mie imi place foarte mult ca IDE-ul pentru PHP imi subliniaza frumos variabilele. Duc dorul unei astfel de optiuni in IDE-ul de C/C++.
Iar ai sarit in altceva.
later:
- probabil devine cert
- e mult mai rapid devine doar cu 1%
Incearca sa prinzi nuantele, please 
Faptul ca e usor de parsat nu inseamna in mod obligatoriu ca e usor de scris un parser. Poate si probabil viteza a crescut foarte mult. Poate doar cu 1%. Poate in 1994 cand a fost creat limbajul aia 1% chiar inseamna ceva, iar in 2017 nu inseamna absolut nimic. Si oricum n-am pretins niciodata ca as fi 100% logic si consecvent
2 Likes
actually this is bad practice, in Ruby arata asa:
Fals, “bad practice” inventat de tine, pe moment, poate.
Less magic, fully explicit
Cred ca expresia pe care o cauti e fully verbose, nu fully explicit. Nu vad ce valoare adauga Module.const_get cand vrei sa instantiezi o clasa, dar okay. Mie-mi place codul sa fie citibil, altora poate le plac “explicit”, orice ar insemna aia.
Citeste tot contextul ffs - era un raspuns la:
$class = "MyClass";
$instance = new $class;
Intocmai. Verbose si nu-i explicit oricat ai incerca tu sa-l prezinti ca good practice. Sa nu mai spun ca din cauza hack-ului de care ai nevoie sa reproduci behaviour-ul din php te obliga sa si faci error handling manual in caz ca clasa nu exista.
Citeste tot contextul ffs - era un raspuns la:
Nu stiu din care parte din raspunsul meu ai dedus tu ca nu am citit tot topicul, dar te rog elaboreaza…
De asemenea, desi cred ca toti stim ca “$” e inutil in PHP, in special avand in vedere ca PHP7 folosese abstract syntax tree, unul din chestiile utile pe care le aduce e autocomplete mai simplu. Cand apas pe $ stiu ca orice autocomplete urmeaza o sa fie o variabila in scope-ul in care am pus $-ul, si nu sunt incomadat de functiile built-in din php.
Dar deja, cum s-a spus mai sus, asta-i nitpicking. Dollar sign-ul are si lucruri bune, dar clar ele nu cantaresc mai mult decat dezavantajele pe care le aduce. (excessive shift+4 anyone?)
1 Like
Wait a minute, faptul de a prelua external strings si a instantia clase din ele pt. tine NU este bad practice?
@dakull My bad mate, chiar am sarit peste chestia aia. You’re right. (for this time only!!!)
Eu sunt foarte curios de ce este asta “bad practice”. Folosita cu cap, bineinteles.
Poftim, am implementat entry-point-ul dintr-un MVC, intr-o juma’ de ora. Hai sa vedem ce-i in neregula cu el si cum s-ar putea implementa mai simplu si mai elegant intr-un alt limbaj.
La câte probleme are PHP-ul asta cu token-ul pentru indentificarea variabelelor mi se pare neglijabilă. Personal mi s-au părut interesante informațiile prezentate de @dakull, nu știam toată povestea deși scriu cod PHP de 15 ani. Fun trivia facts.
Înteleg și de ce poate fi agasant pentru cineva care folosește preponderent ruby, python sau orice alt limbaj fară astfel de vestigii.
Eu m-am obișnuit cu asta pentru ca PHP a fost primul limbaj pe care l-am învățat, pentru că mai tarziu am scris o grămadă de cod cu jQuery, plin de $ și așa mai departe. Să zicem ca am $ blindeness 
6 Likes
“$” este folosit si in Tcl, awk, in unele librarii de regular expressions pentru replace-uri etc. Practic, oriunde e nevoie de mult lucru cu text, e mai usor sa ai ceva de genul:
print hello $name
dacat
print('Hello ’ + name)
sau chiar
print(‘Hello {name}’)
2 Likes
ti-ai raspuns singur 
Desi n-am mai scris PHP de ages - un exemplu rulabil:
class Test {
function code() {
return "limited-scoped-data-or-behaviour\n";
}
}
class Vulnerable {
function code() {
return "full-unscoped-data-or-behaviour\n";
}
}
$external_string = 'Test';
$obj = new $external_string;
echo $obj->code();
$external_string = 'Vulnerable';
$obj = new $external_string;
echo $obj->code();
// => limited-scoped-data-or-behaviour
// => full-unscoped-data-or-behaviour
N-am inteles ce anume e vulnerabil. Vulnerabil la ce? Eu vorbeam de un scenariu de genul cum e mai jos, nu sa folosesti string doar pentru ca poti:
$url_path = parse_url($_SERVER["REQUEST_URI"], PHP_URL_PATH);
$controllers = array(
"/" => array("class" => "Default", "func" => "abc"),
"/test" => array("class" => "Test", "func" => "abc"),
"/test/xyz" => array("class" => "Test", "func" => "xyz"),
"/test/123" => array("class" => "Test", "func" => "123")
);
if(!array_key_exists($url_path, $controllers))
die("Invalid URL!");
$class_name = $controllers[$url_path]["class"] . "Controller";
$func_name = $controllers[$url_path]["func"];
spl_autoload_register(function($class_name)
{
$path = strtolower($class_name) . ".php";
echo "Autoloading $path, for class $class_name...\n";
require $path;
});
$instance = new $class_name;
if(method_exists($instance, $func_name))
{
echo "Calling $class_name->$func_name()...\n";
call_user_func(array($instance, $func_name));
}
else
{
die("Method not implemented!");
}
Next time paste that si nu:
$class = "MyClass";
$instance = new $class;
Si nu poti sa extrapolezi ce minunatii poti sa construiesti plecand de la cele doua linii de mai sus?
1 Like
Ai exemplu mai sus de ce este bad practice iar implementarea ta este varianta cu white-list, nu inteleg ce nu intelegi :))
Eu am inteles ca e “bad practice” simplu fapt ca poti sa instantiezi clase plecand de la un string. Am presupus ca ai inteles ca eu ma refeream la feature in sine, nu la exemplul minimal pe care l-am dat. Logic ca intr-o implementare “adevarata” faci toate testele de securitate posibile. Eu n-am niciodata incredere in inputul primit de la client
bwhahaha. plus inca zece caractere.
EDIT: (ca sa nu mai lungesc thread-ul cu non-informatii)
bad practice nu tine cont de nivelul de cunostinte ale unui programator