Příspěvky

1501

Vývoj / Re:Webove MVC - jak správně provázat Routes a Controllery u RESTu

« kdy: 29. 03. 2018, 22:30:30 »

když máte uri "POST xxx/users/" - je to jasný - voláte něco jako user.POST_controller
když máte uri "POST xxx/posts/" - opět je to jasný - voláte něco jako post.POST_controller

jenže když máte například získat všehny posty daného usera, uri může vypadat nějak takhle "GET xxx/users/:userID/posts", jakej controller na to z výše vyjmenovaných zavoláte? Ha? Žádnej - protože žádnej z výše uvedených tohle nedokáže zpracovat.

Závolá se user.POST_controler s filtrem, že se mají vrátit posty.

To url mi přijde ošklivé, takové neRESTové.

A už tu bylo řečeno, že POST by měla být akce kontroleru (respektive dá se to rozdělit, ale ne mechanicky podle metod).

1502

Vývoj / Re:PHP: Statické volání soukromé instanční metody rodiče

« kdy: 07. 03. 2018, 12:14:13 »

IMHO prostě chybka.

1503

Vývoj / Re:Jak získat data z json_decode v php

« kdy: 18. 02. 2018, 23:35:03 »

To co psal fifi by mělo být správně. Nemáš tam někde překlep?

Pár typů jak to řešit:

Zkus použít print_r() místo var_dump(). Má (někdy) čitelnější výstup.

Ten dump ti říká, že v $obj je pole. Takže zkus dumpnout jen první prvek toho pole:

var_dump($obj[0])

Pak se ujisti, co tam máš, a můžeš se posunout na další úroveň.

1504

Vývoj / Re:Životnost webové aplikace

« kdy: 16. 02. 2018, 23:42:35 »

Deset let není problém.

Když použiješ nějakou webovou nebo serverovou knihovnu tak ona ti bude fungovat i za těch deset let i když už nebude podporovaná. Jen prostě nebude podporovaná, to znamená žádné nové feature. Znám klienty, kteří vesele dělaj na roky neaktuálních technologiích. Ano, není to pro vývojáře pohodlné, ale to je nezajímá, že jo.

Jediný problém bývají nástroje typu WordPress, Joomla a podobně ohledně bezpoečnostních děr (a po pravdě, lidi to taky neřešej).

1505

Studium a uplatnění / Re:Po 4. jsem změnil práci, je tohle česká pracovní kultura?

« kdy: 12. 02. 2018, 01:12:37 »

Ale strávíš tam polovinu života.

1506

Vývoj / Re:Jak vytvořit v PHP objekt kontroleru, jehož název je v poli

« kdy: 31. 01. 2018, 23:05:14 »

Vydím, že chytrolínů je tu plná p*del, ale aby si to někdo zkusil, to ne.. jen urážky a blbý kecy.....

https://exploited.cz/otazky

1507

Vývoj / Re:Bezestavové OOP

« kdy: 31. 01. 2018, 22:59:59 »

Ten TradeProcessor tam nemůžeš namockovat ani setterem, ani reflexí.

Rozdíl mezi konstruktorem a setterem je jen a pouze v tom, že konstruktorem hodnoty nastavuješ povinně, zatímco setterem volitelně.

Proč to tam nemůžu namockovat setterem, vždyť jsem to udělal. Rozdělil jsem práci se třídou logicky na 2 kroky, v 1. se dělá veškerá inicializace, až ve 2. kroku se cokoliv spouští. Díky tomu můžu přes settery přpsat inicializované instance tříd dle libosti mocky.

A, máš pravdu, přehlédl jsem se. No tak pak je to jednoduché. Místo setteru to tam můžeš předat zkrzeva konstruktor. Setter v tomto případě nedává žádný smysl.

Teda, jestli tvé uvažování chápu správně, tak ten setter máš jen kůli tomu, aby si mohl mockovat. Chápu. No, mě to nepřijde vůbec hezké. Je to funkční, ale takové nepřímočaré.

1508

Vývoj / Re:Bezestavové OOP

« kdy: 31. 01. 2018, 12:49:50 »

Tak to udělej třeba v Javě, napiš ekvivalent te tridy Program. Chci videt, jak tam TradeProcessor a Test strkas pres ten konstruktor.

Dělám teď na něčem jiném, ale vidím, že s tím testem na null jen obcházíš Elvise. To v Javě uděláš tak, že definuješ hodnotu atributu už při vytvoření instance objektu. Při zadání patřičného parametru ji změníš.

Uniká mi, co má dělat ten TradeProcessor, ale zběžně tam místo new TradeProcessor() strčím v testu new MockTradeProcessor().

Tohle začíná být už opravdu hodně zoufalé, mírně řečeno. Jak tam strčíš v testu new MockTradeProcessor(), když nebudeš mít setter nad atributem TradeProcessor ve třídě Program?

Obecně řečeno, pokud v nějaké třídě A musíš speciálně vytvořit instanci jiné třídy B a C, tak dpč. asi těžko uděláš konstruktor, který bere třídy B a C. Testovat to, dpč., musíš buďto tak, že tam dáš settery nebo to nasetuješ přes reflexi. A pokud to nasetuješ přes reflexi, příjdeš o automatizovanou refaktorizaci.

Konec diskuzí s tebou, začínám tě považovat za trolla autistického typu.

Předpokládám, že vidíš problém v tom, že ten TradeProcessor krmíš daty, které jsou k dispozici až v tom Program, že? Tak je fakt, že něco takového tam injektovat moc nemá smysl, máš-li to postavené takhle.

Každopádně moc nechápu, proč se tady rozčiluješ mezi konstruktorem versus setterem, versus reflexi? Vždyť to nic neřeší.

Ten TradeProcessor tam nemůžeš namockovat ani setterem, ani reflexí.

Rozdíl mezi konstruktorem a setterem je jen a pouze v tom, že konstruktorem hodnoty nastavuješ povinně, zatímco setterem volitelně.

1509

Vývoj / Re:Bezestavové OOP

« kdy: 30. 01. 2018, 22:53:14 »

OOP je stavove. Ak je to bezstavove, tak to nie je OOP, ale nieco ine.

S tím dokážu žít.

1510

Vývoj / Re:Bezestavové OOP

« kdy: 30. 01. 2018, 21:56:34 »

Pokud není stav sdílený mezi vlákny tak stavovost objektů nikdy nevadila.

Mě jo.

1511

Vývoj / Re:Bezestavové OOP

« kdy: 30. 01. 2018, 21:53:13 »

@BoneFlute

Ne, že by se to neosvědčilo, ale nebyla možnost něco paralelizovat a tudíž stavovost objektů nebyla na závadu.

Paralelizovatelnost je nejčastěji skloňovaný důvod. Ale já v praxi spíše narážím na čitelnost a použitelnost. Immutable objekty jsou prostě víc blbuvzdorný. Je-li tam stav, je s tím hrozně práce.

1512

Vývoj / Re:Bezestavové OOP

« kdy: 30. 01. 2018, 15:18:50 »

že si nemůžu definovat globální proměnné a do každé pomocné metody, kterou budu volat, budu muset propagovat parametry

To není problém.

To mi příjde, že vizuálně zhoršuje čitelnost kódu.

To je otázka zvyku. Posuzovat kvalitu kódu podle počtu argumentů je špatná metrika.

Měl by si se ptát jinak:

- Má smysl, aby ta třída měla více reprezentací?
- Jde paralelizovat?
- Je nutné, aby si udržovala stav?

Obecně je lepší, když si objekt stav nepamatuje. Ano, je to poněkud ústup z původních ideí OOP, ale IMHO se to prostě neosvědčilo. Na druhou stranu jsou věci, které je nesmyslné, až nemožné dělat imutabilní. Například různé akumulátory, loggery, etc. Tedy objekty, jejichž smyslem je různě sbírat data, abych je na konci (nebo i klidně průběžně) zpracoval. Ne, že by to nešlo bez toho, ale někdy je to zbytečně kostrbaté.

Tvůj problém se splitováním velkého množství dat bych udělal jako stavovej, protože stejně potřebuju spolknout celej ten datovej blob, a nějak paralelizovat to stejně nejde.

1513

Vývoj / Re:Rozlišení objektu v PHP

« kdy: 24. 01. 2018, 22:01:02 »

Já pořád nechápu, proč tedy řešíte (string)? Není problém v tom, že by to nevracelo string, je problem v tom výsledku, stejná konstrukce a výsledek je 1 ale očekávaný výsledek je 2.

No tak evidentně to tak úplně stejná konstrukce není, když se to chová jinak, že jo.

1514

Vývoj / Re:Jak funkci předat parametry uložené v poli?

« kdy: 24. 01. 2018, 21:45:19 »

Vkládat celé pole je varianta https://en.wikipedia.org/wiki/Service_locator_pattern obecně považované za antipattern. To, že to není objekt, ale pole je jen nepodstatný detail. Princip a tím i problém je stejný.

Nepleť si předávání pole (zde to ani není pole, ale slovník) se vzorem Service Locator a raději si přečti Clean Code, kde je tento postup doporučován místo většího než malého počtu parametrů.

Princip a tím i problém je stejný.

Ale dosti bylo krmení trolla.

1515

Vývoj / Re:Rozlišení objektu v PHP

« kdy: 24. 01. 2018, 21:43:08 »

... tak jde o to, že kámen úrazu je to, že
 se nedají volat z metody __toString() jiné metody, teda dají ale změny se neprojeví v objektu.

Hehe, to je docela zajímavé gotchas, tuhle ještě neznám.

Podle všeho to vypadá, že se prostě jenom vyhodnocují volání těch dvou argumentů v opačném pořadí (tedy odzadu), než jak by si čekal. Stačí přidat přetypování:

Kód: [Vybrat]

class C{
        public function __toString(){
                return ((string)$this->b) . $this->a->v;
        }
}

Každopádně taky mi to přijde na můj vkus dost překombinovaný.