Prosím o radu s PHP OOP

[Daniel Kozak]

Je to případ dovedení ad absurdum, na kterém je vidět, že rozhodnutí, že to, že private metody budou nevirtuální je "zjednodušení pro kompilátor", které není intuitivní.

Tak ono tady nejde podle me tak o zjednoduseni pro kompilator, ale spise o vykon a moznou optimalizaci. Stejnej problem ma i napriklad jazyk D, ktery sice hodne vychazi z C++, ale zrovna OOP ma vice po vzoru javy.

[Reklama]

[Jakub Galgonek]

Je to případ dovedení ad absurdum, na kterém je vidět, že rozhodnutí, že to, že private metody budou nevirtuální je "zjednodušení pro kompilátor", které není intuitivní.

Tak ono tady nejde podle me tak o zjednoduseni pro kompilator, ale spise o vykon a moznou optimalizaci. Stejnej problem ma i napriklad jazyk D, ktery sice hodne vychazi z C++, ale zrovna OOP ma vice po vzoru javy.

Výkonnostní optimalizace to asi nebude. Třeba takové final metody se volají pomocí invokevirtual, i když by je šlo přímo devirtualizovat. (Ony se tedy nakonec asi devirtualizují, ale jinde a bez ohledu na klíčové slovo final).

Podle mne jde spíše o zjednodušení pro člověka. On stav, kdy můžete překrýt (override) metodu, které je private v jiné třídě, ale nemůžete ji zavolat, přecejen trochu neintuitivní.

[Logik]

Co je neintuitivní se možná neshodem v globálu, ale pokud by možnost předefinování privátních metod byla např. omezená na metody označené jako abstract, tak co by bylo na tom neintuitivní?

Co je neintuitivního na tom, že je možné předefinovat metodu, která je přímo označená jako "todle musíš předefinovat"?

[Jakub Galgonek]

Co je neintuitivního na tom, že je možné předefinovat metodu, která je přímo označená jako "todle musíš předefinovat"?

Pokud je metoda označena "nesmíš o ní vědět" a "musíš ji předefinovat", tak je to prostě neintuitivní kombinace, a proto ji Java zakazuje.

[Ondra Satai Nekola]

Co je neintuitivní se možná neshodem v globálu, ale pokud by možnost předefinování privátních metod byla např. omezená na metody označené jako abstract, tak co by bylo na tom neintuitivní?

Co je neintuitivního na tom, že je možné předefinovat metodu, která je přímo označená jako "todle musíš předefinovat"?

Nemichas private s protected?

[Reklama]

[DW]

nez se clovek do cehokoliv pusti mel by mit aspon nezbytne teoreticke zaklady. je jedno jestli se jedna o kachlickovani koupelny, mdrání nebo OOP.

Škoda že nejde dať like

[DW]

Na rovině faktické pak má PHP zmršenej koncept dědičnosti, takže tam nejde udělat abstraktní virtuální metoda private, takže to takto udělat nejde a musí holt ta metoda bejt protected.

On nejaký OOP jazyk umožnuje abstraktné súkromné metódy?

[Jakub Galgonek]

On nejaký OOP jazyk umožnuje abstraktné súkromné metódy?

Už to tu myslím padlo, v C++ to jde.

[Jakub Galgonek]

Jinak v Javě by se dal přístup k accessibility shrnout jako "co nemohu vidět, to pro mne neexistuje", což je trochu rozdíl oproti C++. Například následující příklad v C++ neprojde:

Kód: [Vybrat]

class A {};
class B : public A {};

class X {
    public:    void foo(A a){}
    protected: void foo(B b){}
};

class Bar {
    void bar(X x, B b) {
        x.foo(b);
    }
};

C++ zahlásí chybu, protože třída Bar nemá přístup k protected metodě X.foo(B). Javě to nevadí, ta prostě zavolá X.foo(A), kterou vidí a je na ten parametr aplikovatelná. Pozor jen, že pokud to budete v Javě zkoušet, tak je dobré mít X a Bar v jiných balíčcích, protože třídy z jednoho balíčku si navzájem vidí (a mohou tedy i volat) své protected metody.

[perceptron]

A které mj. vede k nemožnosti vyjádřit IMHO rozumnou myšlenku, abych zakázal volání funkce kterou musí definovat potomci, protože se vztahuje k nějaké specifické implementaci něčeho, ovšem jelikož ta funkce neudržuje objekt ve "well defined" stavu, tak by tu funkci potomci neměli mít možnost volat.

occamova britva

rozumnych myslienok ktore nemaju podporu v jazyku je viac... napriklad plky voci chybajucej viacnasobnej dedicnosti v jave

zase vsak cim viac konstruktov tym je to vacsie psycho na ucenie sa a vysvetlovanie a chapanie... hec ved c++ vs java je otvoreny priklad (a v inej planete java vs scala)

[m]

napriklad plky voci chybajucej viacnasobnej dedicnosti v jave

Vícenásobná dědičnost chybí v mnoha jazycích a nikde k tomu nemají plnohodnotné uspokojivé řešení.
Konstrukty kterým programátor nerozumí, tak je nemusí používat.

[perceptron]

aktivne nie ale stane sa ze ich bude citat a maintainovat po ostatnych :-))

[Sten]

rozumnych myslienok ktore nemaju podporu v jazyku je viac... napriklad plky voci chybajucej viacnasobnej dedicnosti v jave

Mě daleko víc vadí type erasure v generikách, takže třeba nelze udělat obecný wrapper přes dědičnost. Tohle u Javy trochu nedomysleli, generika jsou spíš pro dynamické jazyky.

[Logik]

....
aktivne nie ale stane sa ze ich bude citat a maintainovat po ostatnych :-))

Jo, to je přesně Javovskej protektivní přístup: někdo by to mohl používat blbě, tak to radši zakážeme.
Pokud je někdo čuník, tak je čuník, a seberestriktivnější jazyk mu nepomůže. A pokud někdo není čuník,
tak proč mu zakazovat užitečné obraty jen proto, že se s nimi dá prasit?

Jinak zakázání abstract private není konstrukce navíc, ale naopak restrikce navíc, stejně jako "devirtualizace"
private metod, z který to vychází, je opět pravidlo navíc a nikoli pravidlo namíň, takže ani ta argumentace
až tak nesedí....

[m]

aktivne nie ale stane sa ze ich bude citat a maintainovat po ostatnych :-))

Na údržbu starého kódu obvykle stačí pasivní znalosti. Když se nová featura ukáže jako přínosná, třeba lambda funkce, stejně se to bude muset naučit tak jako tak.