Finální konstruktor PresenterComponent

Ondřej Mirtes napsal(a):

Ahoj,
lidi mají neustále problémy s tím, že přepisují konstruktor (např. v potomku Controlu či Presenteru) a aplikace jim pak nefunguje (komponenta nepřijímá signály, Presenter taky zlobí). Navrhuji tedy, aby byl konstruktor v PresenterComponent nastaven jako finální, aby k těmto situacím nedocházelo.

To je dobrý nápad – zároveň by to chtělo nějaký mechanismus jako init() nebo setup() automaticky volaný z konstruktoru. Defaultně prázdná metoda.

Ondřej Mirtes: Co by bylo náhražkou? Byla by to poměrně velká zpětně nekompatibilní změna.

Mikulas Dite: To je sice hezké, ale funguje to pouze v presenteru.

Podle mě je to takhle ideální. Špatné překrytí je čistě chyba programátora (z nepozornosti).

pekelnik napsal(a):

startup() je specifická metoda presenteru (určitá fáze zpracování požadavku)

zatímco setup by se volala v konstruktoru a byla by ve všech komponentách

To se mi ani trochu nelíbí. V tom by byl pěkný bordel.

Ondřej Mirtes napsal(a):

Ahoj,
lidi mají neustále problémy s tím, že přepisují konstruktor (např. v potomku Controlu či Presenteru) a aplikace jim pak nefunguje (komponenta nepřijímá signály, Presenter taky zlobí). Navrhuji tedy, aby byl konstruktor v PresenterComponent nastaven jako finální, aby k těmto situacím nedocházelo.

Já bych byl asi pro, ale překvapuje mě, že s tímhle požadavkem přicházíš zrovna ty :)

Přijde mi to trošku zvláštní. V Javě je toto vyřešené mnohem lépe, tam všechny konstruktory všech tříd (kromě java.lang.Object) musí volat buď jiný svůj konstruktor, nebo konstruktor předka. Dokonce je to AFAIK kontrolováno při tzv. verifikaci bytecode. (Jednou jsem na to nejspíš zapomněl a hned mi JVM nadávala.) Dokonce to asi musí proběhnout před prací s metodami rodiče, předáváním this apod. Toto by se tedy nestalo.

Celkově filozofie konstruktorů je IMHO taková, že každé třídě je houby po tom, jaké konstruktory mají potomci. Ať si třeba přijímají něco dalšího. Jen ať prvně inicializují rodičovskou třídu jejím konstruktorem a pak s ní pracují. (Protože předtím by to znamenalo práci s neinicializovanou třídou a tudíž nedefinovaný výsledek.)

Pravda, Presentery jsou trošku specifické tím, že jsou instanciovány nejspíš přes Reflection a tedy mají učitou pevnou strukturu API konstruktoru.

To ovšem nemění cokoli na tom, že to je celkem drastický přístup.

Jinak u Presenterů by se to dalo ještě zkousnout (do Nette 1.0 by to asi nebyl jediný BCB), ale u Controlů nikoli.

Honza Marek napsal(a):

U controlů už to mělo dávno být. Podle mě přepsaný konstruktor controlu je prasárna, pač se pak nedá spolehnout na standardní chování.

Něco na tom bude. I přes to, že je to BC break, jsem pro.

Jo a Datagrid taky přepisuje konstruktor. Dost divoce a moc nerozumim tomu proč.

Já v tom nevidím problém, hlavně že volá parent constructor.

Ještě je tu možnost udělat nějaký lint, který by (aspoň zjednodušeně, nemuselo by to být jak v Javě) kontrolovat volání parent konstruktoru. Asi by ho šlo pro vývoj nějak modulárně připojit k RoLo.

Jo, to je runtime varianta této kontroly. Já mám radši statické kontroly. Ale tady je to celkem jedno.

Tak to už je věc toho člověka co bude chtít posílat do konstruktoru. Pokud nebude připojená přes konstruktor, udělá si to nette samo (pokud použiješ továrničku samozřejmě).

Co když chci, aby si to nette dělalo samo a do konstruktoru posílal jen svoje určitý parametry? Tak to tak udělám. Pak už je problém, že pokud nepoužiju továrničku, laděnka bude řvát, že není připojená k jiné komponentě, ale to už je chyba programátora. Šlo jen o to, jak zabránit programátorům udělat chybu nevolání předka. Když ho volat nebudu, žádná chyba řvát nebude a pak si někdo myslí, že komponenta funguje jak má i když nefunguje (signály).

Tak jsem v Griditu taky musel zrušit konstruktoru parametry. Když jsem je tam nechal a připojoval datagrid hned, tak blblo loadState. Celý strom komponent datagridu se totiž nepřipojil k presenteru najednou, ale postupně, a to dělalo neplechu.