Přesně takto se to používá:
1/ Generovaný kód, jehož znění nevyžaduje schválení člověkem = generuje se na CI serveru (nebo kdekoliv jinde) + necommituje se.
2/ Generovaný kód, který mi vygeneruje stroj, ale musí projít schválením člověkem = generuje se u vývojáře, a pak se commituje.
Má to tyto důsledky:
V prvním případě se jede na tvrdo optimalizace, stroj může cokoliv.
V druhém případě je očekáváno, že to co se vygeneruje musí být co nejvíce čitelné; nejlépe optimalizované pro diff. (A následně se to třeba celé ještě projede první variantou.)
TypoProvidery a podobně jsou jen první varianta. Jen už zakomponovaná do překladače. Jak už tu někdo zmínil. Ve skutečnosti je to ale spousta dalších případů: gcc, javac, scalac, ... etc, kde by tě ani nepadlo uvažovat, že je to jen prachsprostej generátor kódu. A ne, není to něco jiného
Mel bys nejakej netrivialni priklad 2?
Příklad 3: VisualStudio má návrháře UI. Můžeš si tam naklikat, natahat, naarangovat elementy. Ty se potom zapíšou do souboru. Buď do C#, nebo do XAML. V případě XAML se tento ještě zpracovává do výsledného něčeho. C# je part třída, kde máš jednu část, kterou má na starost návrhář, a druhou část, kterou používáš ty jako vývojář pro vlastní opičárny. Když hrábneš do té návrhářské třídy, tak pokud to nepřeženeš, tak se to zpětně promítne do toho návrháře. Osvědčilo se mi do té návrhářské třídy koukat. Lépe si všimnu, že jsem udělal nějakou nepravost. Nebo naopak, při přejmenování nějakého elementu, se přejmenuje i tady a návrhář to v pohodě zkousne.
Hmmm s tim sem nikdy nedelal.
Pamatuju si nejaky takovy udelatko pro Qt a jestli se nepletu tak tam se to do jednoho souboru nemotalo.
Tam byl snad v tom navrhari nejaky dialog pro event binding nebo co... to se mi zda lepsi.
Navic vystup z toho snad bylo nejaky xml a ne primo trida v cilovem jazyce.
Ale kdo vi... uz je to davno
Navic tady jsme trochu dal od generovani neceho ze schematu.
Tady "programator" "programuje". Sice tahanim nejakejch policek po formulari, ale to je jedno... to ze existuje kod a jeho visualni reprezentace je v poradku. Je to jedinny "zdroj pravdy" tak je v poradku ze to commitnu.
Já jsem se nebavil o generování ze schematu. Já jsem obhajoval "generovat kód vždy a všude" v opozici ke "generování kódu je zlo" :-)
Graf si sice muzu vygenerovat ale nikam ho nekomitnu, protoze to stejne pri buildu nikdo nepouzije.
Graf ne, ale informace o těch konkrétních závislostech ano. Chceš tři balíčky s nějakou cca verzí - dostaneš jich stovku s konkrétní verzí. Zkontroluješ, zda všechno funguje a tím, že to commitneš (tu stovku balíčků se specifickými závislostmy) tak uděláš schválení, že takto je to správně.
to fakt v mavenu ani v leiningenu nedelam... A nebo te porad spatne chapu.
Zavisim na balicku A:1.2.3 co zavisi na X, Y, Z.
Y zavisi na P ve verzi 3.14 a ten ma bug.
Moje zavislosti budou:
- P:3.1415 kde uz vim ze je bug opraven a
- A
Maven sam spravne dotahne i X, Y, a Z a P tam budu mit ve verzi 3.1415
ale kdyz se podivam do repositare nikde nenajdu ani zminku o X, Y a Z
OK, Maven to dělá jinak, v pořádku.
Možná jde o to, že u Composeru (a nejen u něj), balíček nezávisí na konkrétní verzi. Takže když by byla vydána nová verze nějakého balíčku, tak by se mohlo stát, že se tam stáhne ona. A to pochopitelně nechci.
Jak to dělá Maven netuším, ale předpokládám, že je tam nějaká chytristika, aby po konfiguraci bylo zaručeno, že se vždy vytvoří stejný graf.