Python - zbožňovaný lidmi?

[Kit]

Po kompilaci skočí Vim na místo, kde byla hlášena chyba. V čem je problém?

V tomto, co ste napisali, je to strasne neprakticke.

V čem je to nepraktické? Kam má skočit?

Tvarite sa, ako by ste nepouzivali nikdy GUI. Skakanie na chyby pri kompilacii, je drevene. Povedzme, ze si chcem pozriet par vyskytov, potom to po castiach pofixovat a pozriet, co mi to urobi v testoch. Zdebugovat testy. Nieco vratit naspat, lebo usudim, ze cast zmeny bola kravina a treba to spravit inak. Co vam poviem, uzasny svet grafickeho pouzivatelskeho rozhrania.  Fixovat vo vim skakanim po suboroch, to by sa radsej na zmenu vysral, len lepil dalsi kod a modlil sa, ze som prilepil spravne. (Robim si zadek, som ateista, nemodlim sa.)

Však jsem nepsal o skákání po souborech, ale na řádek v právě editovaném souboru. Jinde chyba být nemůže. Pokud potřebuji současně pracovat s dalším souborem, otevřu si další tab. V IDE se nedělá nic odlišného.

[Reklama]

[Kit]

Chapem, ze "Kolega" dal trosku udrbany priklad s tisickami tried, no jeho pointu viem pochopit.

Měnit názvy veřejných metod, které se už používají, není refaktoring, ale zvrhlost.

Ak sa zle volaju, nevidim v tom problem.

Nerozumím tomu "zle volaju". Jak ji mohou špatně volat, když ji volají dle definovaného rozhraní?

Když v IDE změním název veřejné metody v nějaké třídě, v kterých projektech se mi změní i její volání?

Mají špatný název,  pane.  Přomintě, že mi nerozumíte.

Do kterých projektů se pak tato změna propaguje? Do všech?

Pokud mají veřejné metody špatný název, tak to někdo zvoral při návrhu. Prostě se ta metoda označí @deprecated, aby ji už nikdo nepoužíval a napíše se nová. Jinak skutečně nevidím důvod, proč měnit názvy metod.

[senior]

Kite, nediv se, že si všichni myslí, že programuješ jen doma a vlastně to ani neumíš. Používáš VIM jak amatér, kolegy nemáš, protože by ti nerozuměli a i s vývojem to bude slabší. Odkdy se nepřejmenovává veřejná rozhraní? Závislé projekty se musí přizpůsobit. Je to úplně běžná věc a ničemu to nevadí. Chudák ten tvůj novej zaměstnavatel, jestli mu tam také vyprávíš takové bejkárny Takže bacha na zkušebku!

Jinak doufám, že lidi, kteří tu většinou píšou, nikdy nepotkám při vývoji, protože by rychle zmizeli, ale za špatného bych byl určitě já

[balki]

Mají špatný název,  pane.  Přomintě, že mi nerozumíte.

Do kterých projektů se pak tato změna propaguje? Do všech?

Pokud mají veřejné metody špatný název, tak to někdo zvoral při návrhu. Prostě se ta metoda označí @deprecated, aby ji už nikdo nepoužíval a napíše se nová. Jinak skutečně nevidím důvod, proč měnit názvy metod.

Aby sa tie metódy volali (překlad: jmenovali) správne, to je ten dovod?  Keď je api hlúpo spravené, treba ho nechať hlúpym, aby nevznikli problémy v iných projektoch?

[Kit]

Do kterých projektů se pak tato změna propaguje? Do všech?

Pokud mají veřejné metody špatný název, tak to někdo zvoral při návrhu. Prostě se ta metoda označí @deprecated, aby ji už nikdo nepoužíval a napíše se nová. Jinak skutečně nevidím důvod, proč měnit názvy metod.

Aby sa tie metódy volali (překlad: jmenovali) správne, to je ten dovod?  Keď je api hlúpo spravené, treba ho nechať hlúpym, aby nevznikli problémy v iných projektoch?

Však proto je označím @deprecated, aby ostatní ten warning viděli a opravili si API. Nemohu přece měnit zdrojáky, na kterých pracuje někdo jiný. Jinak vznikají zbytečné konflikty.

[Reklama]

[balki]

Do kterých projektů se pak tato změna propaguje? Do všech?

Pokud mají veřejné metody špatný název, tak to někdo zvoral při návrhu. Prostě se ta metoda označí @deprecated, aby ji už nikdo nepoužíval a napíše se nová. Jinak skutečně nevidím důvod, proč měnit názvy metod.

Aby sa tie metódy volali (překlad: jmenovali) správne, to je ten dovod?  Keď je api hlúpo spravené, treba ho nechať hlúpym, aby nevznikli problémy v iných projektoch?

Však proto je označím @deprecated, aby ostatní ten warning viděli a opravili si API. Nemohu přece měnit zdrojáky, na kterých pracuje někdo jiný. Jinak vznikají zbytečné konflikty.

Od toho je IDE, aby sa konflikty jednoduchsie riesili. Vo vim riesit konflikt musi byt utrpenie.

[gll]

Už ten Python umí rozhraní a nebo to ještě nedorazilo do dětských jazyků? A co modifikátory přístupu? Takový základy to určitě má, ne? Nebo? A věci jako BOM asi také nepotřebujete, protože jste ještě někde v roce 1991, kdy nic nebylo a dělalo se v textových editorech.

Zastaralý koncept jsou naopak rozhraní. Moderní jazyky mají protokoly.

[Ivan Nový]

Do kterých projektů se pak tato změna propaguje? Do všech?

Pokud mají veřejné metody špatný název, tak to někdo zvoral při návrhu. Prostě se ta metoda označí @deprecated, aby ji už nikdo nepoužíval a napíše se nová. Jinak skutečně nevidím důvod, proč měnit názvy metod.

Aby sa tie metódy volali (překlad: jmenovali) správne, to je ten dovod?  Keď je api hlúpo spravené, treba ho nechať hlúpym, aby nevznikli problémy v iných projektoch?

Však proto je označím @deprecated, aby ostatní ten warning viděli a opravili si API. Nemohu přece měnit zdrojáky, na kterých pracuje někdo jiný. Jinak vznikají zbytečné konflikty.

Od toho je IDE, aby sa konflikty jednoduchsie riesili. Vo vim riesit konflikt musi byt utrpenie.

Refaktoring je jistě potřebný, ale nezapomínejme na to, že je vždy výsledkem chyby návrhu, zaviněné, či ne. A tady jsme se už posunuli od stavu - nebojte se refaktorovat, chyby v návrhu vždy budou, do stavu - kdo nerefaktoruje není, naplácejte to nějak, ono se to už časem urefaktoruje.

A v tomto stavu, de facto změněném paradigmatu, vyvstává otázka, zda jazyk umožňující bezbřehou refakturaci není vlastně na závadu. Podobný neblahý stav, ale jakoby z opačné strany, vedl k zavádění statických jazyků. Dnes menší míra možnosti refaktorovat vede na nutnost myslet více na kvalitu návrhu už při psaní kódu. Což paradoxně byla hlavní motivace při zavádění statických jazyků do vývoje.

[Kit]

Od toho je IDE, aby sa konflikty jednoduchsie riesili. Vo vim riesit konflikt musi byt utrpenie.

Divil by ses, ale není. Jednak Vim tolik konfliktů negeneruje, druhak jejich řešení je pohodička.

Přejmenování používaných metod nedělám zas moc často. Naposledy to bylo výměna insert() za add(), aby to vypadalo lépe. Ovšem i kdybych to neudělal, tak by se houby stalo a je třeba zvážit, zda ti to stojí za ten dlouhatánský commit.

[gll]

Od toho je IDE, aby sa konflikty jednoduchsie riesili.

S konflikty názvů to v Pythonu není tak jednoduché. Často jde o záměrné předefinování něčeho.

[balki]

Od toho je IDE, aby sa konflikty jednoduchsie riesili. Vo vim riesit konflikt musi byt utrpenie.

Divil by ses, ale není. Jednak Vim tolik konfliktů negeneruje, druhak jejich řešení je pohodička.

Přejmenování používaných metod nedělám zas moc často. Naposledy to bylo výměna insert() za add(), aby to vypadalo lépe. Ovšem i kdybych to neudělal, tak by se houby stalo a je třeba zvážit, zda ti to stojí za ten dlouhatánský commit.

Konflikty robia programatori, nie IDE. IDE ich pomaha riesit.
No neviem, uz radsej nic. Pekny vikend zelam.

[atarist]

Kite, nediv se, že si všichni myslí, že programuješ jen doma a vlastně to ani neumíš. Používáš VIM jak amatér, kolegy nemáš, protože by ti nerozuměli a i s vývojem to bude slabší. Odkdy se nepřejmenovává veřejná rozhraní? Závislé projekty se musí přizpůsobit. Je to úplně běžná věc a ničemu to nevadí. Chudák ten tvůj novej zaměstnavatel, jestli mu tam také vyprávíš takové bejkárny Takže bacha na zkušebku!

Jinak doufám, že lidi, kteří tu většinou píšou, nikdy nepotkám při vývoji, protože by rychle zmizeli, ale za špatného bych byl určitě já

Teda musim se Kita zastat jako castecny Javista. Vite kolikrat se prejmenovala metoda v std. library za tech 22 let? Kolikrat se rozsirilo rozhrani? Prejmenovani metody asi 3x (vic jich bylo deprekovanych), rozsireni rozhrani okolo 20, z toho se to dotklo koncaku jen v pripade JDBC. A to se bavime o 6000 tridach (Java a skoro ctvrtstoleti existence! Takze zmena externe viditelneho rozhrani samozrejme je mozna, ale zrovna v enterprise je dost napreshubu

[atarist]

A to se bavime o 6000 tridach (Java a skoro ctvrtstoleti existence!

Ten ksichtik tam je namisto "Java 8". Sorry jako, upravit to tady nemuzu :/

[dustin]

A to se bavime o 6000 tridach (Java a skoro ctvrtstoleti existence! Takze zmena externe viditelneho rozhrani samozrejme je mozna, ale zrovna v enterprise je dost napreshubu

Jenže srovnáváš API knihoven programovacího jazyka s třídami interního informačního systému, na kterém nezávisí žádné externí projekty a je celý v jednom repozitáři i IDE projektu, tedy jej má IDE úplně celý naindexovaný, nejsou žádné další závislosti mimo (protože to je to, co tu celou dobu říkám). Jediná závislost je, že na tom dělá pár lidí, kteří na sebe vidí mezi kancelářemi. Všichni z nich mají celý projekt u sebe, naindexovaný ve svém IDE. Změna -> push -> pull a hotovo. Má-li někdo hodně rozděláno, se změnou se počká. Má-li někdo málo a zrovna se náhodou změna názvu trefí do jeho aktuálních změn (konflikt), třícestný merge v IDE vyřeší během chviličky, obvykle je to drobnost. Žádné kecy kolem, co tu někteří předvádějí, úplně běžný postup.

[Kit]

A to se bavime o 6000 tridach (Java a skoro ctvrtstoleti existence! Takze zmena externe viditelneho rozhrani samozrejme je mozna, ale zrovna v enterprise je dost napreshubu

Jenže srovnáváš API knihoven programovacího jazyka s třídami interního informačního systému, na kterém nezávisí žádné externí projekty a je celý v jednom repozitáři i IDE projektu, tedy jej má IDE úplně celý naindexovaný, nejsou žádné další závislosti mimo (protože to je to, co tu celou dobu říkám). Jediná závislost je, že na tom dělá pár lidí, kteří na sebe vidí mezi kancelářemi. Všichni z nich mají celý projekt u sebe, naindexovaný ve svém IDE. Změna -> push -> pull a hotovo. Má-li někdo hodně rozděláno, se změnou se počká. Má-li někdo málo a zrovna se náhodou změna názvu trefí do jeho aktuálních změn (konflikt), třícestný merge v IDE vyřeší během chviličky, obvykle je to drobnost. Žádné kecy kolem, co tu někteří předvádějí, úplně běžný postup.

Otázkou zůstává: Proč vývojáři přejmenovávají veřejné metody v již hotových třídách, na kterých jsou závislé jiné komponenty jejich aplikace? Nedělají to náhodou jenom proto, že to v IDE jde snadno? K čemu je to dobré a komu to prospěje?