Simulátor příkazového řádku v PHP

Repox: Zajímala by mě (a ostatní určitě taky) tvá odpověď/protiargument na Martinův příspěvek https://webtrh.cz/267674-simulator-prikazoveho-radku-php?p=1093704#post1093704

Napsal Repox;1093702

Co se týče chyb, tak je opravdu ošetřovat nepotřebuji, teda ne tak jak jste patrně zvyklí... Absolutně mně nezajímá jak který příkaz funguje, pokud chci obsah souboru tak si o něj jedním příkazem požádám a třída která tohle má na starost se už prostě o získání obsahu postará, bud jej dostanu nebo nedostanu nic. Pokud nedostanu požadovaný obsah tak se podle toho zařídím dále.

No mna ale zaujima aj preco ten obsah suboru nedostanem. Je rozdiel, pokial ten obsah nedostanem, ze je subor prazdny a je rozdiel, ked ten obsah nedostanem, ze napriklad je subor zamknuty a momentalne z neho nemozem citat. Pokial je napr. zamknuty, tak mozem pockat o pokusit sa citat znovu. Chcel by som ta vidiet, ako si budes pametat projekty v ktorych maz stovky vlastnych tried a tisice procedur. Dalsia vec, ako budes riesit zmenu interface procedury ? Zmeni sa ti pocet parametrov v procedure. Neviem ako v PHP, ale vo Visual Studiu mi IDE zareve, ze procedura s povodnym poctom parametrov neexistuje a kde su tie procedury s nespravnym poctom parametrov.

Napsal Repox;1093732

To je v pořádku, možná jsem nezačal úplně nejlíp a asi si nikdo z reagujících neumí ani představit jak je taková práce jednoduchá. Já použil tuhle třídu mimojiné v jednom mém pluginu pro WordPress a ve výsledku jsem zmenšil kód o skoro 40% a daleko víc jej zpřehlednil.

Možná to chtělo požádat o ukázky kódu například pro konkrétní práce s obrázky, soubory nebo s třeba parsováním RSS kanálů a poté jim ukázat, že není třeba psát tolik řádků kódu, že stačí pouze jeden max dva. Každopádně třídu časem hodím na github a pak se uvidí :)

---------- Příspěvek doplněn 31.05.2014 v 14:27 ----------

samozřejmě, já myslel využití spíše v rámci aplikace u funkcí které jsou více náročnější na výpis dat. Můžu do cache ukládat zcela automaticky pro každý příkaz nebo naopak jen pro konkrétní příkaz. Výhoda je v tom, že mám absolutně pod kontrolou co se bude cachovat a v tom, že nemusím psát mraky dalšího kódu. Cache je taky dočasná tedy při ukončení scriptu se vymaže, nebo trvalá, která se maže po stanovené době.

Další výhoda je v tom, že na konkrétní příkaz můžu napasovat libovolnou funkci. Když mi některá nativní funkce PHP vytěžuje server, můžu si na ní napsat rozšíření a spouštět ji příkazem se zapnutou cache. Pak se provede pouze jednou.

Kód tímto přístupem nikdy nezmenšíte. Ano, na jednu operaci napíšete jeden řádek kódu, ale těch dalších šest stejně máte napsaných někde jinde a dalších dvacet k tomu, aby se kód vykonal. Pokud budete potřebovat cokoliv nestandardního, tak musíte psát novou metodu, pokud byste jen rozšířil původní, díky absenci parametrů vám přestane fungovat všechen předchozí kód. Uvedu příklad, například zmenšení obrázku. Ok, máte příkaz, který zmenší obrázek. Co když budu chtít, aby výsledkem byl zmenšený obrázek, oříznutý do čtverce a výřez byl brán z prostředka? No jste v háji, musíte napsat novou metodu (takže časem těch metod budou stovky, bude v nich binec a ani sám si je nebudete pamatovat). A největší problém tohoto řešení je rychlost. Čím více metod tam budete mít, tím to bude pomalejší a pomalejší a nároky na paměť větší a větší. Pokud jediným přínosem je, že Vám se bude kód psát o něco lépe, je to špatně. Tato "výhoda" by neměla být na úkor výkonu.

Napsal crs;1093842

Repox: Zajímala by mě (a ostatní určitě taky) tvá odpověď/protiargument na Martinův příspěvek https://webtrh.cz/267674-simulator-prikazoveho-radku-php?p=1093704#post1093704

Na většinu jsem myslím odpověděl, co konkrétně vás zajímá?---------- Příspěvek doplněn 01.06.2014 v 11:12 ----------

Napsal qwertr;1093854

No mna ale zaujima aj preco ten obsah suboru nedostanem. Je rozdiel, pokial ten obsah nedostanem, ze je subor prazdny a je rozdiel, ked ten obsah nedostanem, ze napriklad je subor zamknuty a momentalne z neho nemozem citat. Pokial je napr. zamknuty, tak mozem pockat o pokusit sa citat znovu.

Chcel by som ta vidiet, ako si budes pametat projekty v ktorych maz stovky vlastnych tried a tisice procedur.

Dalsia vec, ako budes riesit zmenu interface procedury ? Zmeni sa ti pocet parametrov v procedure. Neviem ako v PHP, ale vo Visual Studiu mi IDE zareve, ze procedura s povodnym poctom parametrov neexistuje a kde su tie procedury s nespravnym poctom parametrov.

Na zjištění konkrétní chyby jsem myslel, ještě to není dokonalé, ale momentálně můžu u každé třídy/příkazu použít "last_error", který vrátí text chyby pokud k nějaké došlo. Takže pokud nedostanu požadovaný obsah můžu zavolat tento příkaz, který vše vysvětlí. Mimoto chyby tohodle typu se automaticky zapisují do logu.Parametry jsem řešil dlouho, ale momentálně můžu použít parametrů kolik chci aniž by došlo k chybě. Pokud použiji špatný příkaz, nebo mi nějaký parametr bude chybět dojde samozřejmě k chybě, ale všechny příkazy jsou psané tak abych zadával pouze určitý počet parametrů. Parametry které jsou navíc a nemají žádnou funkčnost se zahodí, protože nemají vliv na funkčnost.---------- Příspěvek doplněn 01.06.2014 v 11:29 ----------

Napsal Jan Stejskal;1093866

Kód tímto přístupem nikdy nezmenšíte. Ano, na jednu operaci napíšete jeden řádek kódu, ale těch dalších šest stejně máte napsaných někde jinde a dalších dvacet k tomu, aby se kód vykonal. Pokud budete potřebovat cokoliv nestandardního, tak musíte psát novou metodu, pokud byste jen rozšířil původní, díky absenci parametrů vám přestane fungovat všechen předchozí kód. Uvedu příklad, například zmenšení obrázku. Ok, máte příkaz, který zmenší obrázek. Co když budu chtít, aby výsledkem byl zmenšený obrázek, oříznutý do čtverce a výřez byl brán z prostředka? No jste v háji, musíte napsat novou metodu (takže časem těch metod budou stovky, bude v nich binec a ani sám si je nebudete pamatovat). A největší problém tohoto řešení je rychlost. Čím více metod tam budete mít, tím to bude pomalejší a pomalejší a nároky na paměť větší a větší.

Pokud jediným přínosem je, že Vám se bude kód psát o něco lépe, je to špatně. Tato "výhoda" by neměla být na úkor výkonu.

To ale není nic nového nebo špatného, tohle je v každém frameworku a v podstatě v každé třídě a funkci. Prvně něco nadefinuju třeba na stovkách řádků a pak to jen na pár řádcích použiji. Tady jde o tu výhodu úspory psaní viz třeba příkaz curl nebo manipulace s obrázky. To že mám někde definované nějaké funkce mě vůbec nemusí zajímat, napsal jsem je jednou a ano dal jsem si s nimi práci, ale odted je můžu použít kdokoliv, kdekoliv a kdykoliv a hlavně daleko jednoduším vyvoláním než v případě normálního programování, odpadá inicializace tříd, DI a spousta dalších věcí.Včera jsem si udělal například (cca za 40 minut) připojení k db přes dibi. Nemusím zjišťovat syntaxi zápisu, nemusím vůbec nic. Jen napíšu "dibi connect $access_data" a pro provedení SQL dotazu třeba "dibi query $sql" což je daleko úspornější na psaní než použít ofic. zápis kódu z "manuálu" dibi.Co se týče paměti, je momentálně úplně zanedbatelná.

Šmankote jestli si chceš vytvořit nějakou supertřídu FerdaMravenec - práce všeho druhu, tak si jí klidně vytvoř, není to sice OK, ale to ti nikdo nebere. Ale uveď mi jediný důvod, proč použít místo třeba$term->imgResize(200, 200, "./background.png"); tvoje$php->Term('img resize 200 200 ./background.png'); Proč? Vždyť se tak úplně nesmyslně vzdáváš i té ubohé podopry ze strany IDE, kterou ti je v PHP shopno nabídnout. Ty si opravdu neuvědomuješ, jak je to nesmyslné sázet název metody i všechny její parametry v jednom řetězci? Co práce v týmu? Co když ten kód bude po tobě někdo číst, jak se bude v tom chaosu orientovat? Takhle možná naprogramuješ třístránkový web, ale jak takhle můžeš naprogramovat třeba nějaký CMS, vždyť to je nemožné. Snažíš se vrátit programování 20 let nazpět a možná ještě dále.---------- Příspěvek doplněn 01.06.2014 v 12:41 ----------A to bych chtěl ještě vidět, jak vypadá ta tvoje metoda Term(), do které jsi natlačil půlku webu. Nebo počkej, vlastně nechtěl.

Fakt by som nechcel takto programovat. Pokusit sa v tom nieco zrefaktorovat, tak by to bola nocna mora. Povazovat za vyhodu nepotrebu vytvarat objekty, no prepac.Neviem ako ty, ale ja urobim sem tam preklep. Tu hladat preklep v texte prikazu alebo nazve procedury, no pekne dakujem. Vies aky som rad, za inteligentne IDE, kde mi napr. staci napisat nazov objektu. Dat bodku a vypise mi vsetky public procedury. Ked si ju vyberiem, tak mi ponukne help k danej procedure, zoznam parametrov a info ku kazdemu parametru.Len tak by ma zaujimalo ci maz nejake vzdelanie, ktore sa tyka programovania a aky najvetsi projekt si naprogramoval. Skus to odhadnut v hodinach. Maz skusenosti s udrzbou nejakeho projektu ? Pod tym myslim nieco takym sposobem, ze ten system bezi napr niekolko rokov a priebezne sa donho doplna nova funkcionalita, upravuje existujuca. Casovo napr. z mesiacia tak tyzden venujes tomu beziacemu projektu.

Napsal qwertr;1093908

Vies aky som rad, za inteligentne IDE, kde mi napr. staci napisat nazov objektu.

Já nechci být rýpavý, ale fakt mám pocit, že autor vlákna programuje v notepadu a nemá ani potuchy o tom, co to IDE je.

Napsal Repox;1093877

Na většinu jsem myslím odpověděl, co konkrétně vás zajímá?

---------- Příspěvek doplněn 01.06.2014 v 11:12 ----------

Na zjištění konkrétní chyby jsem myslel, ještě to není dokonalé, ale momentálně můžu u každé třídy/příkazu použít "last_error", který vrátí text chyby pokud k nějaké došlo. Takže pokud nedostanu požadovaný obsah můžu zavolat tento příkaz, který vše vysvětlí. Mimoto chyby tohodle typu se automaticky zapisují do logu.

Parametry jsem řešil dlouho, ale momentálně můžu použít parametrů kolik chci aniž by došlo k chybě. Pokud použiji špatný příkaz, nebo mi nějaký parametr bude chybět dojde samozřejmě k chybě, ale všechny příkazy jsou psané tak abych zadával pouze určitý počet parametrů. Parametry které jsou navíc a nemají žádnou funkčnost se zahodí, protože nemají vliv na funkčnost.

---------- Příspěvek doplněn 01.06.2014 v 11:29 ----------

To ale není nic nového nebo špatného, tohle je v každém frameworku a v podstatě v každé třídě a funkci. Prvně něco nadefinuju třeba na stovkách řádků a pak to jen na pár řádcích použiji. Tady jde o tu výhodu úspory psaní viz třeba příkaz curl nebo manipulace s obrázky. To že mám někde definované nějaké funkce mě vůbec nemusí zajímat, napsal jsem je jednou a ano dal jsem si s nimi práci, ale odted je můžu použít kdokoliv, kdekoliv a kdykoliv a hlavně daleko jednoduším vyvoláním než v případě normálního programování, odpadá inicializace tříd, DI a spousta dalších věcí.

Včera jsem si udělal například (cca za 40 minut) připojení k db přes dibi. Nemusím zjišťovat syntaxi zápisu, nemusím vůbec nic. Jen napíšu "dibi connect $access_data" a pro provedení SQL dotazu třeba "dibi query $sql" což je daleko úspornější na psaní než použít ofic. zápis kódu z "manuálu" dibi.

Co se týče paměti, je momentálně úplně zanedbatelná.

Myslím, že mi ani trochu nerozumíte. Vy musíte mít v paměti třídu, která obsahuje naprosto vše bez ohledu na to, zda to použijete nebo ne. To je na tom špatně, v jiných frameworcích obvykle vytváříte instanci pouze toho, co potřebujete. Možná toho ta vaše třída zatím umí tak málo, že to nemusíte řešit, ale jak jsem vám naznačil, aby byla použitelná, bude časem obsahovat stovky funkcí a to už není nic zanedbatelného.

@Repox Zahodit třídu Term, z jejích metod udělat běžné, ne-OOP procedury a funkce, stanovit neprůstřelný systém jejich pojmenovávání a začít je organizovat do knihoven, koupit si pásku přes oko, motorku a koženou bundu s nápisem "Fuck frameworks, fuck OOP!" a začít programovat procedurálně. Od té doby nechodit pro rady k mainstreamovým programátorům.