obal nad stringem

vlna

Ahoj,
za prve diky za Nette. Zacinam s nim a hlavne veci jako Object, String, Image se mi neskutecne libi.
Trochu me trapi terminologie, Presenter misto Controller mi jde dost proti srsti, ale co se da delat.

K veci: jde jen o napad ohledne dalsiho syntax sugar, zaujalo by nasledujici ?

str(‚Hello world‘)->startsWith(‚Hell‘);

Kde str je pomocna funkce, ktera by napr. startsWith prelozila na volani String::startsWith(‚Hello world‘, ‚Hell‘);
Moznosti, jak to implementovat je spousta, je to jen okamzity napad.

Jod

No fúúúúj. Hádam si nechceme z nette spraviť bordel

vlna

:-) v pohode. Me se to libi kuli jasnemu odliseni parametru, kde php u string funkci neni uplne konzistentni v poradi $haystack / $needle.
Byl to jenom „vystrelek“.

piler

vlna napsal(a):

Ahoj,
za prve diky za Nette. Zacinam s nim a hlavne veci jako Object, String, Image se mi neskutecne libi.
Trochu me trapi terminologie, Presenter misto Controller mi jde dost proti srsti, ale co se da delat.

Nieco o MVC a MVP na zdrojaku

Honza Marek

:-) v pohode. Me se to libi kuli jasnemu odliseni parametru, kde php u string funkci neni uplne konzistentni v poradi $haystack / $needle.

Ty parametry jsou ve stejném pořadí, jako kdyby ten první byl objekt (například v Javě).

// java
haystack.startsWith(needle);

// nette
String::startsWith($haystack, $needle);

vlna

Honza M. napsal(a):

Ty parametry jsou ve stejném pořadí, jako kdyby ten první byl objekt (například v Javě).

Jasne, tech metod v Nette stringu neni tolik a ty konzistentni jsou. Objektova syntax (prave jako napr. v Jave) mi v tomhle pripade prijde jen prehlednejsi, protoze nemusim uvazovat nad poradim a okamzite vidim, co je objekt a co mu posila zpravu.
Neco podobneho pouziva i jQuery ( $("").xxx ). Nekomu to sedne, nekomu ne, nekomu to nesedne v tomhle pripade … . Cilem nebylo to tu nikomu nutit.

Jinak architektonicky rozdily mezi MVC a MVP beru. Jen mi je blizsi vyclenit nazvoslovi v rovine implementaci vs navrhovych vzoru, pokud to vede k nejake konvencni terminologii, ve ktere se nejak shoduji dalsi vyznamne frameworky (Zend, Cake, Struts2(java) ) – aspon v tom smyslu, ze napr. pouzivaji termin Controller i kdyz ani jeden z nich nejspis nepouziva „cistou“ puvodni MVC architekturu.
Evoluce „MVC“ urcite pujde dal. Pokud zmenite mezi Frameworkem X a X+1 navrhovy vzor (jak se mozna stalo ve Struts a Struts2), nechate puvodni nazvy trid s podobnou odpovednosti (nazvy implementace) nebo je budete menit podle terminologie pouzitych navrh. vzoru?

Tim jenom vysvetluju, proc jsem psal, co jsem psal, nerad bych, aby z toho byl flame, Nette se mi libi.

David Grudl

Objektová syntax je pěkná, ale bez nativní spolupráce PHP by se to asi neujalo.

vlna

Ok, rozumim. Jen pro String a par sikovnych metod by to asi vazne nemelo cenu a mozna to k pekne KISS jadru s vychytavkama proste nesedi. Kazdopadne diky za diskusi vsem.

phx

Ono kdyby se vsude daly objekty tak je to dalsi zbytecne volani kodu jen pro pohodli programatora. Ono kdyz se to vezme kolem a kolem tak rozdil v

$objekt->neco;	// pouzeje je synatx sugar z predka Object
// a
$objekt->getNeco();	// pristoupi se primo

je nekolik radku kodu. A kdyz takhle nacitate desitky vlastnsti tak uz to muze byt znatelne. Otazka zni jak moc to muze zpomalit App. A ve vysledku programator usetril 5 znaku (get()).

vlna

Asi tezko rict, jak to komu sedne. Ja treba prave syntax sugar rad a nevadi mi ho zaplatit nejakou tou milisekundou :-). Ve vysledku je to pomalejsi, ale zase v porovnani s uzkym hrdlem aplikace (db, ldap, soubory, sockety…) myslim skutecne bezvyznamne.
U toho Object je to myslim zrovna tak, ze kdyz syntax sugar nekdo nebude chtit pouzivat, jediny overhead bude trochu kodu v __call, ktery php bude muset (max. jednou per request) sparsovat navic (volani existujicich public metod primo pujde mimo magic __call() )
Ty obalove veci jsem myslel podobne, jen jako alternativu, kterou si programator bud includne a pouzije ji, nebo ne a pouzije normalni pristup. Kazdopadne uz za to nijak nebojuju.

romansklenar

Já mám taky rád syntax sugar, on pak má člověk z toho PHP trošku lepší pocit. Spíše bych ale víc uvítal, kdyby Nette\Object po zavolání metody $obj->toString() sám zavolal $obj->__toString().

phx

Mozna by slo udelat neco jako u kesovani, ze by se onen sugar prevedl do zakladni syntaxe PHP. Otazka zni zda to ma vyznam:)

kravčo

romansklenar napsal(a):

Já mám taky rád syntax sugar, on pak má člověk z toho PHP trošku lepší pocit. Spíše bych ale víc uvítal, kdyby Nette\Object po zavolání metody $obj->toString() sám zavolal $obj->__toString().

Ja by som možno šiel ešte ďalej a zavolal $obj->__toString(TRUE)… lenže Nette\Object štandardnú __toString() neobsahuje…

David Grudl

romansklenar napsal(a):

Já mám taky rád syntax sugar, on pak má člověk z toho PHP trošku lepší pocit. Spíše bych ale víc uvítal, kdyby Nette\Object po zavolání metody $obj->toString() sám zavolal $obj->__toString().

Není lepší (string) $obj?

romansklenar

Jasně :) jen když mám ale Template a chci mu předat ten skrytý parametr, tak nezbývá než použít to __toString() :(