CRANK:
TENCOKACISTROMY:
To jsem přesně čekal mno...
C# ke svému oboru ani nepotřebuji a učí se to u nás v jednom jediném předmětu... Pro mě je stěžejní C, Assembler a skripty v Matlabu a to si dávám v pohodě... OOP ale nedávám a nemám ani sílu a chuť se to učit.. Proto poprvé za celé své studium volím užití práce někoho jinýho...

TENCOKACISTROMY: Potkáme se tam ;).

NECROMAN: Tak to se na tebe asi pujdu kouknout :).

Prave jdu z toho druheho testu "zaklad vyvoje metro aplikaci v C#" a bylo to teda tezsi, nez jsem cekal - tech 70% asi nedam. Hodne veci tam bylo na toast notifikace, tile updaty, prace s gesty, search a share kotnrakty .Treba na xaml a stylovani toho bylo fakt malo. No ale bylo to zdarma a dost jsem se toho naucil :)

MAIMONIDES: Muzes pouzit Fasterflect. Na zaklade reflection urcis se ma delat, a ten Fasterflect pak udela dynamicky delegat, kterej nahradi get/set u properties/fields, volani metod atd... Nemusis se pak trapit s emitovanim il kodu (udela to za tebe).

Code DOM sice vypada pekne, ale imho je mensi zlo pouzit ty T4 sablony z duvodu snizeni komplikovanosti kodu pro lidi co prijdou po tobe.

MAIMONIDES: Ale ta Reflection se nemusí dělat pořád (pomalu). Tím jsem myslel si při spuštění programu vygenerovat (Reflection.Emit/Code DOM/…) metody/třídy, které se pak používají prakticky normálně.

Zajímavé reakce, díky..
Možná jsem se vyjádřil zavádějícím způsobem. Je to implementace messagingu v rámci high level client server síťové knihovny(Badumna) v .Net..

Tady je pro zajímavost trochu detailnější popis motivace..
Zprávy jsou všechny děděný z třídy BaseEvent, která obsahuje jen proměnnou Nonce pro implementaci blokující odpovědi na otázku v jinak async client server prostředí. Krom toho obsahuje pouze abstraktní metody. Jednotlivé zděděné zprávy pak sobě implementují pouze serializaci a deserializaci a konstruktor, který mechanicky přiřadí proměnné, což je taky opruz, protože to je byrokracie a nepřišel jsem na to, jak to implementovat přes compile-time - než jsem zjistil, že to nejde. Používat reflection nejde, protože to by bylo moc pomalé. T4 na to asi bude fungovat, ale jestli to bude přehledný je věc druhá a budu to zkoumat...

Každá zpráva je určena pro jeden typ události a jeden typ cílového serveru, tj de/serializace je bez větvení a jakékoli chytrosti.

De/serializace probíhá potom tak, že se genericky de/serializuje třída a podle ní zbytek..


No a právě odesílání a zpracovávání deserializovaných eventů je to, proč jsem sem psal a ptal se na to vytváření názvů a tiše doufal, že to půjde preprocesorem.


Pojmenování těch eventů má svá pravidla a funkce pro jejich odesílání a zpracovávání taky. Je to takhle udělaný aby to bylo srozumitelný i pro cizí lidi co přijdou po mě a aby přidávání nových eventů nebo luštění starých vyžadovalo naprosté minimum intelektuálních schopností a námahy a relativně omezené api..

BUTHRAKAUR: Jenze aby jsi zjistil typ deserializovanyho objektu, tak musis odnekud zjistit jakej je. A odkad ho zjistis?

Imho je uplne ok reseni, kdy mas tu obrovskou hromadu metod odekorovany nejakym atributem, ktery najdes a udelas si na ne delegaty, jenz si strcis do nejaky hashtable a podle toho je pak poustis.

Navic se ten vygenerovanej kod bude mnohem lip debugovat pri ruznej "chutovkach" - a ze jich umi bejt v sitovy komunikaci hodne :).

TENCOKACISTROMY: jj, takhle jsem to tak nejak odhadoval a je to v souladu s tim, co jsem psal. Proste deserializujes nejakej object a ted ho musis podle jeho typu handlovat. Reseni Handle**() bude v sobe obsahovat megaswitch na spusteni ty spravny HandleObjectOfTypeX(). Tomu spusteni retezu handleru nic nebrani IMO a je to daleko cistsi reseni..

BUTHRAKAUR: To uz zalezi na tobe. Muzes mit treba "hlavicku" podle ktery urcis ktery ty svy metode/objektu/tridu/etc... to predas. Nebo ty metody muzes mit rozprostreny pres porty.

Vem si treba takovou komunikaci pomoci JSON. Ma sice u sebe metadata o fieldech/properties ale uz ne o typech. Muzes pak vyzadovat/predpokladat ze ti prijde obalka, ktera specifikuje nazev metody ktera se ma spustit. A z reflection podle parametru dotycny metody pak teprve zjistis jakejch trid budes vytvaret instance.

TENCOKACISTROMY: z toho pole bajtu stejne ale musis napred dekodovat, co je uvnitr, abys tu zpravu moh nejak handlovat.. nebo jak se po prijeti pole bytu urci, ktera Handle**() se ma spustit?

BUTHRAKAUR: Protoze existuje nemaly mnozstvi komunikacnich sitovych protokolu, ktery si v datech nenesou meta-data o tom jaky data nesou. Proste se poslou data a druha strana si je ma "nasekat" spravne. Prikladem muze byt protobuf.

Je sice hezky, ze z objektove spravne by jsi mel pouzit nejaky rozhrani IMessage, ale kdyz proste prijde pole bajtu kde jsou raw data bez meta-dat tak se muzes jit klouzat :).

TENCOKACISTROMY: pochopil jsem, ze do tech trid sahnout nemuze... "komunikacni protokol" ve mne nejak nic relevantniho k tomu problemu neevokuje. chce nejak handlovat furu ruznych messages, takze proc nemit neco jako chain of responsibility?

IMessageHandler
{
bool CanHandle(object/IMessage message);
void Handle(object/IMessage message);
}

desi mne predstava tridy MegaHandler + mega-switche, jestli jsem dobre pochopil navrhovane reseni :)

BUTHRAKAUR: Jestli to ma pro komunikacni protokol, tak spousta z nich nedovoluje pretezovani funkci, ani polymorfismus. Takze se to pak obchazi prave zpusobem, kdy si pro kazdou z moznosti udelas zvlast metodu, ktera to resi.

A protoze to je prave silenej opruz, tak je dobry ten kod generovat a nepsat ho rucne. Protoze to je v podstate jen ctrl+c, ctrl+v, ctrl+h.

MAIMONIDES: "..na každou třídu specializovanou funkci.." - nechybi tam nekde dedicnost? pripomnelo mi to http://www.antiifcampaign.com/ , ale mozna jsem jen spatne pochopil zadani.. :)

MAIMONIDES: Cili na zaklade nejakyho objektovyho modelu chcete vygenerovat kod, kterej zajistuje komunikaci po siti? Na to jsou T4 celkem dobry.