Omezená dědičnost (je něco lepšího než OOP?)

[zboj]

https://developer.apple.com/videos/wwdc/2015/?id=408

Když uz jsme u toho, nevíte někdo, proč v C# udělali tak debilně extension methods v cizích statických třídách?

A v čem je to debilní, resp. jak by to mělo být?

Má to být přímo v tom rozhraní, jako v Javě.

Java nemá extension metody vůbec, ta má jen defaultní metody, ne? Navíc u defaultních metod musíte mít možnost rozhraní měnit (tj. přístup k jeho kódu).

Extension metody v C# jsou jen syntaktický cukr - kdyby mělo jít rozšířit existující rozhraní (bez možnosti ho přímo měnit - např. rozhraní z jiné assembly) nebo implementovat rozhraní pro existující třídu (bez možnosti ji přímo měnit), vyžadovalo by to změny v CLR (případně obejít CLR).

Výhodou stávajícího řešení je, že můžete mít více implementací jedné extension metody a není třeba měnit CLR.

BTW může třída ve Swiftu mít více implementací jednoho protokolu?

Může mít více implementací jedné metody.

[Reklama]

[Natix]

Tady ale směšuješ dvě různé věci. Defaultní metody v Javě slouží jednak k omezené vícenásobné dědičnosti a jednak k tomu, aby bylo možné bezpečně rozšiřovat interfacy, které jsou součástí veřejných API. Druhý bod byl Oraclem prezentován jako jejich hlavní selling point, tzn. že defaultní metody jim umožnili rozšířit do té doby zamrzlé API kolekcí. Sranda je to, že nakonec k tomu prakticky vůbec nedošlo a veškeré funkcionální operace se místo kolekcí dostaly do nového typu - streamů.

Extension metody v C# naproti tomu slouží k rozšiřování tříd, nad kterými nemám kontrolu (jsou součástí SDK, knihoven atd.) a to v Javě dodnes není možné. Proto např. Guava definuje spoustu statických tříd pojmenovaných plurálem třídy, nad kterou operují (Strings, Ints, Iterables, Lists atd.). Takže pak můžu dělat toto: Lists.filter(list, predicate), ale už ne tohle: list.filter(predicate).

Jenže v C# to jde i pro rozhraní.

Teď si asi nerozumíme. Jestli jde o třídu/rozhraní/trait/whatever je jedno. Rozdíl je v tom, že zatímco v Javě mohu defaultní metody umisťovat pouze do svého vlastního kódu, tak v C# lze extension metodami rozšiřovat i typy, které nevlastním.

Jinak řečeno, extension metody jsou nástroj jak pro autora API, tak pro jeho klienta, default metody naproti tomu pouze pro autora.

[zboj]

Tady ale směšuješ dvě různé věci. Defaultní metody v Javě slouží jednak k omezené vícenásobné dědičnosti a jednak k tomu, aby bylo možné bezpečně rozšiřovat interfacy, které jsou součástí veřejných API. Druhý bod byl Oraclem prezentován jako jejich hlavní selling point, tzn. že defaultní metody jim umožnili rozšířit do té doby zamrzlé API kolekcí. Sranda je to, že nakonec k tomu prakticky vůbec nedošlo a veškeré funkcionální operace se místo kolekcí dostaly do nového typu - streamů.

Extension metody v C# naproti tomu slouží k rozšiřování tříd, nad kterými nemám kontrolu (jsou součástí SDK, knihoven atd.) a to v Javě dodnes není možné. Proto např. Guava definuje spoustu statických tříd pojmenovaných plurálem třídy, nad kterou operují (Strings, Ints, Iterables, Lists atd.). Takže pak můžu dělat toto: Lists.filter(list, predicate), ale už ne tohle: list.filter(predicate).

Jenže v C# to jde i pro rozhraní.

Teď si asi nerozumíme. Jestli jde o třídu/rozhraní/trait/whatever je jedno. Rozdíl je v tom, že zatímco v Javě mohu defaultní metody umisťovat pouze do svého vlastního kódu, tak v C# lze extension metodami rozšiřovat i typy, které nevlastním.

Jinak řečeno, extension metody jsou nástroj jak pro autora API, tak pro jeho klienta, default metody naproti tomu pouze pro autora.

Jasně, mně se jen nelíbí, jak se to zapisuje. Ve Swiftu prostě napíšu "extension String ..." a v ObjC "@interface NSString ()" a můžu rozšiřovat. V C# by to mělo být něco jako "partial class ..." (a místo partial třeba extension). Je to jen syntax, ale teď je to nelogické.