Kdy bude Nette aneb

jedná-li se o free soft, potom změnit a oznámit.
jedná-li se o placený soft, potom změnit a udělat support pro platící
jedná-li se o open-source, změnit, komu se to nelíbí, může si editovat source

jinak asi nejlepší je udělat kopii třídy s novým názvem a prohozenými parametry a v documentaci napsat k původní deprected

Nevím, jestli nejsem mimo mísu, ale co kdybys to udělal takhle?

Normálně appendFor přejmenoval na append, ale s tím, že bys vytvořil novou třídu

function appendFor($bo­ol,$objekt) {
VyhodNekdeNeja­kejWarning(‚toh­le je deprecated, ale to zas tak moc nevadi‘);
return $this->$append($objek­t,$bool);
}

?

Noví uživatelé by používali append a staří zakrnělí by mohli (minimálně ještě nějakou dobu) nechat to původní..

Já, protože jsem zvyklý číst mezi řádky, jsem na rozdíl od předchozích komentátorů pochopil o co jde, tak mohu i fundovaně poradit. Má rada je: Měl bys předat vývoj komunitě, ta MILUJE takovéhle dohady a má nástroje, jak je efektivně řešit! (Cože? Tys nikdy neslyšel o project fork?)

PS: Vzhledem k tomu, že pro podobné projekty doporučuji licenci DPL, tak možnost A je tou správnou volbou…

HLA DGX A

Asi to není programátorské, ale co to nějak zprasit, nechat pár měsíců obě funkce, a pak tu starou zahodit?

Já bych to udělal takto:

1. zjistil bych si jméno uživatele počítače
2. jakmile dojde k použití zmiňované funkce tak bych zobrazil hlášku např: „Odhalili jsme vaše tajné webové stránky: www.dgx.homo.com – a teď o Vás víme pravdu!“

(za „dgx“ v odkazu lze napsat cokoli, nejlépe právě jméno zjištěného uživatel pc)

No vydíš a teď můžeš ten název tý funkce klidně změnit aniž by tě někdo za to buzeroval protože všichni zalezou do kouta a budou se stydět !!

Cháá to jsem to jsem to vymyslel to čumíte !

IMO je to o motivaci.

Pokud daný software píšeš primárně pro sebe, a zveřejňuješ ho jen proto, že by byla škoda si ho syslit, pak se nekompatibility nebát – komu se to nelíbí, jeho problém.

Pokud to píšeš primárně pro získání uživatelů (nemůžeš se koukat, jak se lopotí s o třídu horšími nástroji, chceš pomocí toho nějak vydělávat, apod.), pak zpětnou kompatibilitu maximálně držet. Každého ztraceného uživatele je tady škoda.

Tak či onak nic neměnit v bugfixových a asi ani „minor“ releasech. A v changelogu vyznačit změny, které mají na kompatibilitu vliv – takhle to má hezky udělané DokuWiki, kde je v changelogu (http://wiki.splitbrain.org/wiki%3Achanges) vyznačeno, co může způsobit problém při upgradu na novou verzi. Mě pak stačí vědět, že si musím projít ovykřičníkované položky a zbytek changelogu můžu ignorovat.

Takový dlouhý článek a celý o tom, že v PHP chybí @Deprecated?

Ta nová verze generátoru píše sice málo, ale zeširoka!

#2 Aleš Janda: se mi velmi líbí.

To přejmenování funkce je jen příklad!

#1 noname: #2 Aleš Janda: jinými slovy, znamená to udělat ještě něco navíc a zanést si kód zpětně kompatibilními konstrukcemi. Ano samozřejmě je i tohle rozumná cesta.

Noname, píšeš „jedná-li se o open-source, změnit, komu se to nelíbí, může si editovat source“. Budeš to tak vnímat, i když se ti updatem na WordPress 2.1.39 rozpadne web? Řekneš si – pohoda, jdu editovat source?

No já bych udělal udělal kompromisem:
function appendFor($bo­ol, $objekt) {
return $this->$append($objek­t, $bool);
}

Ale jinak:
HLA DGX A

ne, vážně… Začni úvahou, pro koho to děláš. Jestli primárně pro sebe, tak neváhej a měň. Pokud to píšeš s vidinou toho, jak to dáš lidu, tak měň a dodej nějaký „fix.php“ skript, ve kterém poskytneš překlad „starých“ volání na „nová“, a dodej, že v příštím release už nebudou a že to je silně deprecated.

Možnost B bych uvažoval pouze v případě, že se jedná o „komunitní“ dílo a jmenovaná funkce je základní částí interface…

Předělat to celé a zvednout major version o jedna.

Nebo ještě jinak – dát si trochu práce navíc a napsat si nejdřív „Deprecated“ knihovnu. A napříště bys tenhle problém řešil způsobem c), tedy např. přidáním řádku do deprecated.php

deprecate(
   'manipulator->appendFor(%1,%2)',
   'manipulator->append(%2,%1)',
   WARN_LOG
   );

Ale jinak tohle je přesně důvod, proč jsem odpískal jakýkoli projekt, všechno jsem vždy dělal free a bez záruky – protože support, správa verzí a podobný opičárny zabíjí programování.

#13 pixy: A vláda zabíjí lidi…

Sorry za ten OT komentář o Nette u Arthura… Safra :)

Pro ostatní – http://zapisnik.maly.cz/…-konkurs.php, komentář 11 :D

Správný postup je IMHO zachovat zpětnou kompatibilitu, a to i mezi major verzemi.

Tedy nechat appendFor(blbe, blbe) a přidat metodu append(gud, gud).
No a napsat to do changelogu.
Pokud to nahradíš, napíše o tom RH negativní blogspot.

HLA DGX a

jinak te to bude cely zivot flustrovat

chlapi, vy ste to nepochopili… chcel povedat, ze Nette este nebude, lebo by musel premenovat manipulatora…

#14 MiSHAK: Vláda ne, to Chuck Norris…

Nejprve bych chtěl říct, že je podle mne lepší nejdřív vypulírovat dílko, které má jít ven, tak, jak to člověk umí co možná nejlépe. Proto chápu, že nechceš vypustit svůj framework „příliš“ brzo.

Co se týče takovýhle změn, je podle mne lepší starou funkcionalitu nahradit novou. Sice se možná updatující uživatelé budou ptát, kam se poděla tahle funkce, ale zase si ušetříš odpovědi na dotazy „a jaký je rozdíl mezi těmahle dvěma funkcemi“ a „proč je to tu dvakrát, když to dělá to samý“ a může to dojít tak, že bude tvá snaha o zpětnou kompatibilitu odměněna označením „open source bastl“.

Zpětná kompatibilita už podle názvu může táhnout software zpět..

#20 Trupík: Dobrý přístup. Takový majkrosoftí.
Oni se ti uživatelé nebudou ani tak ptát kam se poděla tahle funkce, jako spíš, proč mi najednou přestalo všechno fungovat a proč si to mám všechno programovat znovu.

Právě ta zpětná nekompatibilita táhne software zpět. Vývojáři se velmi zamyslí, zda přejít na novou verzi se všemi důsledky, jako přepracování spousty aplikací, anebo zda jim postačí verze původní.

jinak řečeno nette bude až bude hotový :)

ještě že syslím v ZF :) což ovšem neznamená že se na to dílo rád nepodívám

#21 Lokutus: občas i zpětná kompabilita táhne software zpět protože si sebou přenáší neduhy starších verzí…občas je prostě potřeba říct ne :)

#21 Lokutus: #23 Jakub Podhorský: spis si mysim, ze #20 Trupík: narazil na neco, na co komentatori, nabizejici reseni pred nim, nepomysleli. Ze i kdyz se udela software dokonale zpetne kompatibilni, aby se autor vyhnul supportu, ze neco, co fungovalo, najednou nefunguje, tak se najde nekdo dalsi, kdo bude mit pro zmenu potrebu hladat ve zdrojakach zbytecne veci navic treba jen proto, ze zrovna bude mit nezvladatelnou chut na Nette najit nejake chyby…

Takze HLA DGX C, protoze C je vzdy spravne…

HLA DGX A

už jen pro to, že to tu ještě nebylo :)

#23 Jakub Podhorský: Záleží na tom, kde se změna provádí. Takovýto framework – asi žádná velká tragédie. Prostě si vývojáři pro správu starších projektů ponechají v záloze i starší knihovny.
Ale u nějaké komplexní platformy bych už se hodně rozmýšlel. Pak je většinou lepší ukončit vývoj, přejmenovat to a začít na zelené louce znovu.

Většina seriozních platforem podporuje zpětnou kompatibilitu až ke své první verzi, přičemž spravují rozsáhlou dokumentaci deprecated elementů.

Porušit zpětnou kompatibilitu může znamenat ztrátu důvěry a pak záleží na každém, zda se mu to vyplatí. Já chápu, že čisťoučký a vyvoněný kód stimuluje erotogenní zóny vývojáře, ale ne vždycky to jde.

Já teď také řeším podobný problém, jako dgx. Mám framework na Dominu, kde je skriptová knihovna pro práci se soubory. Ta obsahuje dvě třídy. Ta jedna třída je špatně napsaná, ošklivě se jmenuje a je příšerně nabobtnalá. Potřebovala by rozdělit na tři jiné, přidat hromady metod a nějaké zbytečnosti vyházet. Nezbývá mi nic jiného, než napsat ty tři nové třídy a tuhle ponechat, jak je. Kdybych zlikvidoval zpětnou kompatibilitu, byla by správa starších projektů mnohem komplikovanější, protože bych musel složitě řešit, ve které verzi jádra jsem měl jakou změnu. Takhle mohu při takové změně u všech starších projektů jednoduše přepsat design z nové šablony a nemusím nic dalšího řešit. Během pěti minut mám všude zaktualizované já­dro.

#24 zirafka: Jasněže se šťouralové a další divná zviřátka vždycky najdou, ale na jejich názoru přeci nikomu nesejde, ne? 

K té dokumentaci. Předpokládám, že si píšeš k metodám komentáře phpDoc, proto bych se vykašlal na psaní tutoriálů či manuálů (pokud něco takového plánuješ) a nechal pouze odkaz na stažení frameworku (rozhodneš-li se dát Nette světu). Kdo bude mít o Nette opravdu zájem, vygeneruje si API dokumentaci a princip MVC si nastuduje jinde…

#26 Lokutus: ano já s tím souhlasím…opak se netvrdím…osobně si ale myslím že stačí občas změnit číslo major verze a uživatele na to upozornit a v případě zájmu pracovat na starší verzi což v dnešní době krásně můžeme vidět na PHP což je podle mě taky řešení ale taky ne uplně ideální. všechno je holt o kompromisech

Rozeslal jsem HLA DGX A na deset různých čísel (včetně pěti náhodně nalezených), doufám, že se všechny započítají…

Předchozí články o Nette (a diskuze pod nimi) pro mě byly silně inspirující. Pokud nenette, tak bych byl rád alespoň za další podobné články.

#20 Trupík: narazil jsi hřebíček na hlavičku!

Software by měl jít ven ve chvíli, kdy je takřka hotový, a pak se podobným věcem vyhnu. Sice to popírá „otevřený vývoj“, ale takovým věcem jsem stejně nikdy nevěřil.

Bohužel, je tu ještě taková zkušenost: Když je knihovna funkční, hotová, perfektní a ke spokojenosti ji používám, cca za měsíc mě z ničeho nic napadne myšlenka, update, která knihovnu udělá ještě mnohem rafinovanější. Ale znamená předělat klíčové části.

A jsem tam, kde jsem byl.

Takže když dnes mám něco „hotového“, tak stejně vím, že za nějakou dobu se to může změnit.

Mimochodem, je velmi dobrá zásada psát programy tak, aby jedna konkrétní věc šla udělat právě jedním způsobem. Tato zásada i celá diskuse ukazují, že čistý návrh a kvalitní kód stojí proti zpětnokompati­bilnímu opensource.

Kdy bude Nette?

Framework je pro mě velmi klíčová záležitost a prostě chci mít absolutní svobodu kdykoliv cokoliv změnit a neohlížet se. Proto se těžko dává jako open source ven.

#32 David Grudl: HLA DGX A … je klid!

Líbí se mi, jak tu všichni slintají nad nějakým chimérickým projektem neznáme funkčnosti a kvality.

Kdyby jen nečuměli a makali, mohli už mít knihovnu svoji a možná lepší než ten nikým neviděný originál!

Jsem pro udržení současného stavu. Jednou za půl roku návnada, ale uvolnění stále v nedohlednu. Bude z toho legenda!

#32 David Grudl: prostě chci mít absolutní svobodu kdykoliv cokoliv změnit a neohlížet se. "…

A preto si radšej všetko kódim sám a len veľmi ťažko prijímam nejaké hotové riešenia.

#31 David Grudl: To je myslím celkem žádaný stav snad u všech vývojářů, kteří se snaží nezakrnět. Docela se bojím doby, kdy si přestanu myslet, že už vše znám a žádná z mých aplikací nebo komponent nepotřebuje dalšího vylepšování a je bezchybná.
Většinou je to tak, že až konfrontace s okolím (zákazník, komunita, …) a časem ukáží, na co všechno jsem mohl myslet a co udělat lépe. Dokud však nejsem vnitřně přesvědčen, že mám vše hotovo na úrovni současných znalostí a možností, také se mi také nechce s produktem ven a v tomto se s Tebou shodnu – pokud se nejedná o zakázku s daným termínem, to je však o něčem jiném.
Radu neposkytnu, osobně mohu použít atributu Obsolete a při kompilaci dostat warning jak daný programový element správně použít.
– J.

Řekl bych, že to je jeden z důvodů, proč se používá systém pozvánek – produkt nejprve dostanou ti, kteří jsou schopni zásadní změny vstřebat a zároveň mohou poskytnout smysluplnou zpětnou vazbu.

Doporučuji to udělat stejně – dej Nette nejdřív jenom těm, kteří o něj opravdu stojí a které podobné změny neotráví, ale naopak je přivítají (protože nepatří do skupiny „Ach jo, zase musím měnit kód“, ale do skupiny „Paráda, konečně se zbavím toho protivného true“). Ono se to časem asi rozšíří, ale pokoutně – nikdo si nebude moci nárokovat podporu. Zároveň získáš zpětnou vazbu – ne třeba přímo ve formě návrhů na zlepšení, ale ve formě podnětů, na základě kterých tebe osobně napadne myšlenka #31 David Grudl: ne za měsíc, ale třeba za týden.

A potom teprve dej produkt veřejně ven.

#9 David Grudl: updatem wordpresu (ne tedy minor 2.x.x na 2.x.x+1 ale třeba „sub-major“ 2.x na 2.x+1 se nějaké věci opravdu změnily a ten kdo by na nich byl závislý v nějakém skinu, tak by se mu layout mohl rozpadnout. Ale vývojáři to dali dopředu vědět, je tu navíc možnost sledovat přímo aktuální změny atd. Navíc když se jedná o něco kruciálního co se ne všem uživatelům zamlouvá, tak velmi rychle přijde plugin, který třeba staré chování nějak imituje. A když by to byla blbost, tak by to ani neprošlo, případně by tu zpětnou kompatibilitu někdo ještě před vydáním doprogramoval
u změny major verze x na x+1 pak wordpress vývojáři slíbili podporu na následujících x let (tj. opravy bezpečnostních chyb)

V reakci na #37 Jakub Vrána: se dobrovolně hlásím k testování a čtení kódu.

#39 MiSHAK: Já kdyžtak taky, ale pochybuju, že to DGX dá k dispozici, ovšem po vysvětlení důvodů se ani nedivím.

Naprosto chápu všechny rozpaky. Jelikož jsem také programátor, tak si to přesně dokážu vybavit – programuji nějakou chytrou knihovnu za využití jiného, cizího hotového skriptu. Cizí skript se mi v něčem nezdá, protože nevypadá jako můj kód – co s tím? Když bych nějaký svůj větší projekt pustil teoreticky do oběhu, byl bych rád, aby si někdo, kdo si bude prohlížet zdrojový kód, musel zvykat na různé druhy syntaxe nebo pojmenovávání proměnných? Nebyl. Vše bych změnil tak, aby kód vypadal unifikovaně. Také bych ho potom daleko raději používal.

Takže hlasuji pro první možnost – upravit Manipulator.

Vždycky je lepší mít pěkný pocit z vlastní dobré práce, než se užírat tím kolik lidí to štve a kolik ne. Těm se stejně nezavděčíš.
varianta a

ale ta varianta s pozvánkama není taky špatná, nejřív pro ty, co k tomu mají co říci a je to „plodné“ a pak případně pro ty ostatní. (já mezi plodné nepatřím, i když se na nette těším)

HLA DGX A

Moc bych to neřešil ;) Existuje takové staré dobré pravidlo o softu by Debian Comunity – „Nová verze výjde, až bude čas.“

..já bych si rozhrnul závěsy, záclony a začal se kochat kvetoucí a zelenající se zahradou a zpěvem ptactva.. pak bych počítač vypnul, a šel ven.. 

Ty jsi frajer! :)

Osobne bych hlasoval rovnez pro variantu a). Ja osobne stojim pred stejnymi problemy, ujal jsem se zesnuleho projektu Mojavi 3 a vydal jej pod oznacenim Sanders. Pro pripadne zajemce, k dispozici na adrese http://framework.sanders.cz. Jedna se rovnez o MVC framework, coz jak jsem vyrozumel, ma Nette byt. Nechapejte me jako vetrelce, v zadnem pripade nemam v umyslu nejak pretahovat zdejsi uzivatele, volba frameworku je zcela svobodnou vuli programatora, jen nabizim pomocnou ruku ten, kteri hledaji solidni MVC framework.
Jsem popriprade ochoten Nette take testovat a pripominkovat, pokud by mel autor zajem.

Ahoj Davide,
neuvažuješ, že by si svůj Nette framework (i nehotový) mohl ukázat na semináři php frameworků, který se bude konat 13. října v Praze?
Myslím, že by to určitě hodně lidí přivítalo možná i s nadšením 

Ptám se jako pořadatel. Více info o semináři je na stránkách http://konference.php5.cz

#48 Václav Stoupa: rád. Teda teď z hlavy nevím, jestli už něco 13. října nemám, ale jestli ne, tak jo ;)

#49 David Grudl: Posílal sem ti mail, nespadnul do spamu?

Nette existuje, videli jsme ho :)

HLA DGX A

A co tak vydat nějakou alfa verzi, aby jsme se s tím naučili dělat a nehleděli na to jako vyoraná myš? (můj případ  )

BTW: na Nette jsem narazil nedávno, tak mám možná hloupý dotaz. Bude k tomu help, nebo to považuješ za tak intuitivní, že nebude potřeba?

Takže zítra už slavnostně vyjde to Svatoplukovo Nette?

#53 Linus: Kdo ví. Ale byl to veřejný slib, že do konce listopadu dgx nette vydá. Tak věřme, že to opravdu bude.