Převezmi Zenify, podpoř Nette

@TomášVotruba Mile rad, ale bohuzel jsem ty balicky nikdy nepouzil. Snad se nekdo najde, kdyby ne, tak se ozvi.

@enumag Na Symnedi jsem zapomněl, patří tam samozřejmě taky. Měl bys teda zájem?

@Felix Díky, že ses ozval! Vytvořím maintainer skupinu a přidám ti je. Zatím se nikdo jiný neozval. Případně je pak můžeš přidat sám.

@enumag Jasně, to dává smysl.

Přidám tě k Zenify. Můžeš si udělat tým a přidat si ty, o které máš vyloženě zájem:

• Zenify/CodingStandard
• Zenify/DoctrineMigrations
• Zenify/DoctrineFixtures

Symnedi/EventDispatcher – Kdyby/Events jsou imho příliš komplikované a chtěl bych je vyměnit za něco jednoduššího – tohle vypadá jako zatím nejlepší možnost

Souhlasím.

Symnedi/Validator – aktivně vyvýjím Kdyby/Validator takže tohle bych označil jako deprecated s linkem na Kdyby – nevidím v Symnedi/Validator žádný přínos oproti Kdyby a Kdyby/Validator zatím není overcomplicated jako jiné Kdyby balíčky – máš jiný názor?

Jasně. Tento jsem zakládal, protože jsem myslím potřeboval otagovanou verzi.

Symnedi/Security – použití Symfony/Security místo Nette/Security mám v plánu, ale asi ne nijak brzy – dokud s tím nezačnu tak udržovat tohle by byl asi největší problém ze všech balíčků protože Symfony/Security nerozumím

Myslím, že to není moc rozšířené (nikde jsem o tom nepsal a v praxi se nepoužívá AFAIK), takže tady by šlo o maintanance just in case, ne vývoj.

Symnedi/SymfonyBundlesExtension – touto cestou bych asi nešel, symfony bundly bývají příliš komplikované a raději mám kontrolu nad tím co dělají pomocí vlastního extension pro nette/di – ale samozřejmě jsem tento balíček nezkoušel takže mne můžeš zkusit přesvědčit

Tento jsem udělal kvůli nevytváření kol per framework. Např. https://github.com/…ician-bundle etc.

Editoval Tomáš Votruba (27. 12. 2015 21:47)

Mmm, co mě napadá:

• Zenify/CodingStandard – vyzkoušet, jestli něco není v php-cs-fixeru, případě neduplikovat a využít
• Zenify/DoctrineFixtures – přejmenovat na Alice, bo už to Fixtures vůbec nepoužívá
• Zenify/DoctrineMigrations – dát jim péči a napsat článek o použití, protože jsou populární :)

To je asi tak vše.

Z výše zmiňovaných aktivně používám pouze Zenify/CodingStandard, nicméně u tohoto projektu rád pomohu jak budu moct.

@enumag
ad 1., 2. – Pak mám pocit, že vývoj Zenify coding standard by neměl moc smysl. Pro mě je největší kouzlo je možnost používání uppercase TRU, FALSE a NULL. Beru je totiž jako předdefinované konstanty a ne jako klíčová slova jazyka a proto mi dávají smysl uppercase. Jak se kdo co naučí. A Zenify mi dává tu možnost je v uppercase mít. Určitě bych zachoval podle Nette Coding standard buď uppercase nebo lowercase, ale nemixovat.
ad CS-Fixer – tento problém neřeším, v PHPStormu to na mě řve už při vývoji, že to formátuji špatně, takže se do situace, abych to musel „Fixovat“ nedostanu. A na to jeden „initial“ fix když převezmu nějaký projekt mi to přijde jako overkill do balíčku.
ad Simplify – Kouknul jsem na ty přidané coding standard a některé mi dávají smysl (například InterfaceSniff), s některými zas osobně nesouhlasím (AbstractClassSniff), ale to zas jenom protože často používám místo „abstract“ slovo „base“. (ach, jak mě BasePresenter špatně vychoval…)

Co je za problém s codeception vážně nevím, sám Codeception používám, tak nevím na co přesně narážíš.

Do budoucna určitě přijde velmi brzo na řadu podpora pro php7, a proto nejspíše nějaká implementace PSR-12

@enumag Ano, myslím si, že to tak asi vyjde nejlépe.

@enumag patrickkusebauch