Jak se vypořádat s Nette\Object

David Grudl

Titulek je lehce nepřesný, protože třídu Nette\Object nechci jakkoliv měnit. Snad jen pokud by se v nějaké příští verzi PHP stal její název problematický kvůli tomu, že jde od PHP 7.1 o rezervované slovo, vznikl by alias. V plánu mám ale nahradit použití Nette\Object uvnitř frameworku traitou, podobně jako se už stalo například v Latte.

Otázka tedy je, které schopnosti Nette\Object by traita měla mít.

Co vlastně všechno Nette\Object umí:

striktnost: vyhození výjimky při přístupu k neexistujícím členům s napovídáním přelepů
emulovat property $prop pomocí metod setProp() a getProp() / isProp()
volat event handlery v poli $onEvent přes virtuální metodu onEvent()
extension metody
method gettery do proměnné $method = $obj->method
volání closury umístěné v proměnné $obj->x pomocí $obj->x()
magické gettery a settery s typovou kontrolou definované pomocí anotací @method
přístup k reflexi přes $obj->reflection a případně anotacím, pokud je přítomen balíček nette/reflection

Některé věci se osvědčily, některé méně, některé jsou i po 8 letech existence velmi důležité a PHP je stále neumí nativně nahradit.

Striktnost se jednoznačně osvědčila. Protože PHP 7 při volání neexistující metody nebo přístupu k neexistující statické proměnné vyhazuje výjimku Error, zvážil bych časem z Nette\MemberAccessException, které vyhazuje Object, udělat potomka třídy Error.

Property – s odstupem let jako největší problém properties vidím to, že existují dva způsoby, jak zapsat jednu věc, což vede k míchání dvou přístupů a z toho plynoucí nekonzistenci v kódu. Mělo by se používat buď $obj->x, nebo $obj->getX(), ale ne obojí. Abych se sám vyhnul nekonzistencím, přestal jsem je prakticky používat, krom výjimek jako třeba $presenter->template nebo v šablonách.

Podporu properties je z hlediska kompatibility nutné zachovat i v traitě, ale změnil bych ji tak, aby nebyly by convention, ale by configuration, tj. budou fungovat pouze properties definované pomocí anotace @property, @property-read nebo @property-write. Anotace navíc eliminují magičnost celého řešení.

Kvůli kompatibilitě by v příští verzi fungoval i přístup k properties bez anotace, ale s varováním.

Event handlery via onEvent() hodnotím jako syntaktic sugar, který si své uplatnění našel a jsem pro jej zachovat v traitě beze změny. Tj. i by convention, bez anotace, protože magická metoda není veřejným rozhraním.

Extension method taktéž hodnotím jako syntaktic sugar, který si své uplatnění našel, a byť je v určitých ohledech sporný, ~~asi bych jej v traitě zachoval.~~ Update: asi spíš ne, zachovám je nad formulářem, kde se v drtivé většině používají, a případně na dalších místech, když o to bude zájem, a jinde budou vyhazovat varování.

Přidávat extension metodu pomocí SomeClass::extensionMethod('getAbc', function () {}) má nevýhodu v tom, že načte autoloadingem třídu SomeClass, vhodnější je proto použít Nette\Object::extensionMethod('SomeClass::getAbc', function () {}). Nebo existuje i řešení bez Object: Nette\Utils\ObjectMixin::setExtensionMethod('SomeClass', 'getAbc', function () {}). Původní SomeClass::extensionMethod by mohla být označena anotací @deprecated nebo odchytávána přes __call, aby nebyla součástí API.

Method gettery našly využití při nastavování event handlerů, například $form->onSuccess[] = $this->formSucceeded. Ukázalo se ale, že opomenutí závorek může vést k vážným chybám, např. $user->isLoggedIn je vždy truthy, což dělá jinak elegantní jazykové rozšíření velmi sporným.

Kvůli závažnosti jsem ještě ve verzi 2.3 přidal varování při použití s funkcí začínající předponou get|is|has bez povinných parametrů. V budoucnu bych tuhle věc asi úplně opustil, takže v další verzi Nette by fungovala už jen s varováním.

Volání closury v proměnné – nejspíš zcela nevyužívaná a zároveň nekonfliktní feature. Jelikož v PHP 7 bude možné totéž docílit pomocí ($obj->prop)(), opustil bych ji a v příští verzi by fungovala opět jen s varováním.

Magické settery a gettery – vychytávka, která šetří psaní rutinních setterů a getterů, a jejíž velkou výhodou je typová kontrola. Využívala to řada tříd v Nette 2.2 (příklad), Nette 2.3 od toho upustilo čistě kvůli výkonu. Protože vlastnost nebyla zdokumentovaná, nepředpokládám širší užití mimo framework.

Tahle věc ve světě PHP 7.0 a dnešních editorů už nemá opodstatnění. V příští verzi Nette by ji traita měla podporovat kvůli kompatibilitě, ale opět jen s varováním.

Reflexe: tahle vychytávka mi připadá fajn, ale tipuji, že je v praxi tak málo využívaná, že má smysl ji opustit (tj. zachovat v traitě s varováním). Možná by se dalo do nette/reflection přidat další traitu, která by metodu getReflection() přidala zcela plnohodnotně, bez varování, s anotacemi.

Traita by tedy podporovala

striktnost jako dosud
emulované property ale s anotací, jinak varování
event handlery jako dosud

A vypadly by (tedy zatím by fungovaly s varováním):

method gettery
volání closury
magické gettery a settery
reflexe
extension metody krom formulářů, viz diskuse

Namístě je ještě otázka, zda samotnou traitu nerozdělit na několik dílčích, které by podporovaly jen určitou vlastnost. To IMHO technicky nejde. Navíc si myslím, že striktnost autor třídy chce vždy, a dále pokud nechce property či handlery, tak je prostě nepoužívá/neanotuje. Tím, že vyžadují ještě „aktivaci druhým krokem“, ničemu nepřekáží.

Aktualizace: vzniknou nejspíš dvě traity, jedna čistě pro striktnost (asi Nette\Strict) a druhá pro striktnost, property (ale s anotací) a event handlery (možná Nette\StrictPlus).

David Matějka

Namístě je ještě otázka, zda samotnou traitu nerozdělit na několik dílčích, které by podporovaly jen určitou vlastnost.

byl bych pro oddelenou traitu Strict

David Grudl

…ale to IMHO technicky nejde.

Šlo by udělat Strict pro ty, co chtějí jen strict vlastnosti a „konkureční“ (např.) NetteObject se všemi vlastnostmi pro samotné Nette, nahrazující Nette\Object.

Ale nepůjde nic jako namixovat si use Strict, Events, ExtensionMethods.

David Matějka

@DavidGrudl ~~tak zrovna tohle by se nechalo vyresit – ta „velka“ traita by pouzivala tu Strict (s aliasovanyma metodama)~~

+1, takhle jsem to myslel :)

Šaman

Se souhrnem souhlasím. Jen magické settery a gettery pomocí anotací používám docela často – nejvíc v repozitářích. Předek mi třeba na get($id) vrací Entity, zatímco konkrétní repository si to pomocí anotací upraví třeba na Book a pak funguje našeptávání i nad výsledky z repozitáře.

castamir

Extension metody mi prijdou jako docela slusny zlo. V minulosti jsem je pouzival jako rozsireni napr. pro formulare (pridani vlastnich formularovych prvku typu datepicker ci captcha), ale melo to spoustu trhlin

spatna dohledatelnost v API
spatna dohledatelnost, kde se extensionMethod vola resp. kde by se volat mela
IDE nenapovi, bez pomoci nejake anotace ani nemuze a anotaci ve vyse uvedenem priklade muzu dat jen do kodu puvodni tridy (blbost, pri updatu pres composer mi zmizi) nebo podedit, ale to uz muzu dopsat tech par radku do podedene tridy, ne?

Vytvareni vlastnich base trid (pro formulare, kontejnery, komponenty, ale i pro zakladni presenter) se mi ostatne mnohokrat vyplatilo a v kazdem projektu pouzivam popr dale dedim od techto trid, ikdyz na zacatku nemusi mit zadny zmeneny obsah.

Takze za me extensionMethod zrusit uplne…

enumag

@DavidMatějka Tohle jsi už viděl? :-) https://github.com/…trictObjects

Osobně s výjimkou strict nechci vůbec nic z Nette\Object takže mi tenhle balíček stačí.

@DavidGrudl Bude to součást nette/utils nebo samostatně?

Editoval enumag (30. 3. 2016 22:15)

Honza Marek

Extension metody fakt někdo používá? Já to nepoužil ani jednou.

David Matějka

@Šaman to ale nesouvisi s nette\object, ne? (nebo jsem to spatne pochopil)
@enumag jj videl :)
@HonzaMarek ja jednou, nez jsem pochopil, ze je to instantni zlo :D

Unlink

@HonzaMarek ale pluginy ktoré používame ich využívajú…
https://github.com/nextras/forms/#…
https://github.com/…aControl.php#L93
https://github.com/…ontainer.php#L501

David Grudl

Šaman napsal(a):

Se souhrnem souhlasím. Jen magické settery a gettery pomocí anotací používám docela často

Nevím, jestli myslíš skutečně magické settery a gettery, které generuje Nette\Object, pokud ano, tak tady má nadále smysl dědit od Nette\Object a nepřecházet na jednodušší traitu.

Honza Marek napsal(a):

Extension metody fakt někdo používá? Já to nepoužil ani jednou.

Používá se to poměrně hodně u formulářů.

castamir napsal(a):

Takze za me extensionMethod zrusit uplne…

Pokud se to hodně používá, nelze to zrušit. Možná by se to dalo povolit jen nad formulářem (a případně jinde) a v jiných situacích vyhazovat varování.

castamir

@DavidGrudl je to IMHO bad practice – opravdu bych to již dále nepodporoval. Klidně si extensionMethods dej do skupinky „podpora už jen s varováním“. Použití „jen někde“ je podle mě taky špatný nápad. Pokud to chceš zachovat jen pro formuláře, tak to dej opravdu jen do formuláře (přímo do třídy třeba Form), ale do nové podoby Nette\Object to raději nedávej.

Šaman

Jasně, sorry, nepoužívám to přímo jako magické settery (už jsem to použil, ale ne běžně), nýbrž jako PhpDoc anotaci kvůli napovídání IDE. Takže na Nette\Object nezávisle.

Filip Procházka

Já používám na vlastní prvky formuláře traitu

use Nette\Forms\Controls;

/**
 * @method Nette\Forms\Container|Controls\BaseControl|Controls\MultiChoiceControl|Controls\SubmitButton offsetGet($name)
 */
class BaseForm extends Nette\Application\UI\Form
{
	use ExtensionControls;
}

/**
 * @method Nette\Forms\Container|Controls\BaseControl|Controls\MultiChoiceControl|Controls\SubmitButton offsetGet($name)
 */
class Container extends Nette\Forms\Container
{
	use ExtensionControls;
}

trait ExtensionControls
{
	public function addContainer($name)
	{
		/** @var ExtensionControls|Container $this */
		$control = new Container();
		$control->setCurrentGroup($this->getCurrentGroup());
		return $this[$name] = $control;
	}


	// sem přijdou další typy prvků

}

Perfektně to kamarádí s PhpStormem (a napovídá custom prvky i nad kontejnery a i přes ArrayAccess).

David Grudl

Uvažuji nad názvem traity. Ta jednoduchá bude Strict, stejně jako v Latte, dibi nebo Texy. A ta plnokrevná, hmmm … napadlo mě třeba StrictPlus.

Váhám nad namespace, jestli podobně jako Nette\Object (nebo jako nette výjimky) použít Nette\Strict, nebo Nette\Utils\Strict.

ali

David Grudl napsal(a):
hmmm … napadlo mě třeba StrictPlus.

Stricter :-)

GEpic

ali napsal(a):

David Grudl napsal(a):
hmmm … napadlo mě třeba StrictPlus.

Stricter :-)

Stringent dle mého, viz – https://in.answers.yahoo.com/question/index?… nebo https://en.wiktionary.org/wiki/stringent#…

Editoval GEpic (1. 4. 2016 8:41)

blindAlley

Mě se hlavně vůbec nelíbí, že samotný framework používá Nette\Objects a nadále v tom chce pokračovat. Ani to nové řešení s traitem Strict v latte a dibi se mi nelíbí. Je to celé od začátku do konce o magii, která zásadním způsobem mění chování objektů v php. Už jen to, že se do všech objektů, včetně komponent a presenterů, přidává magické __get, které vrací referenci se mi vůbec nelíbí. Hlavně pro to, že všechny tyhle magie jsou náročné na výkon. Magické metody __set/get/call atd. jsou jedna z nejpomalejších věcí v php. Dále pak také pro to, že tenhle syntax sugar se bez hlubších znalostí špatně čte a je tím pádem WTF. Také to mění chování chyb, padají z toho výjimky, které končí v těch magických metodách místo toho, kde je ta chyba normálně.

Jsem jednoznačně pro to celé to komplet z frameworku, resp. všech balíčků, vyházet a nechat to jen v nějakém balíčku bokem, ať si to použije kdo chce. Nejraději bych už od 2.4, případně pak v nové major verzi. A přestat to využívat v sandboxech a příkladech.

Editoval blindAlley (1. 4. 2016 10:14)

amik

Jsem pro to určitě maximálně oddělit, na Objectu mi nejvíc vadí právě to, že kombinuje několik nesouvisejících věcí zároveň (třeba strict je dobrá vychytávka, na druhou stranu jsme na našich projektech od použití Object úplně ustoupili kvůli method getterům a emulaci properties, aby to někdo z vývojářů omylem nepoužil).

Imho by to tak velký problém být neměl, jedině některé věci budou zřejmě vyžadovat Reflection trait, ale tak si ho prostě vyžádají (trait může "use"nout jiný trait). Nebudou mi ale cpát třeba emulaci properties, kterou nechci.

Seznam za mě:

striktnost: super, využil bych, může stát samostatně
emulovat property: nechci (a to explicitně – přesvědčí mě to třídu/trait celou nepoužít i za cenu obětování dalších funkcionalit)
volat event handlery v poli $onEvent – jednoduché a užitečné, proč ne (ale také samostatně)
extension metody – klidně bych vypustil (nějak explicitně mi nevadí jako třeba emulace properties, ale snažím se je nepoužívat)
method gettery do proměnné $method = $obj->method – souhlasím, vyhodit, pokud se nevymyslí elegantnější řešení nenáchylné k chybám programátora
volání closury umístěné v proměnné $obj->x pomocí $obj->x() – vyřeší PHP 7, mohlo by být jako samostatná traita, osobně to nepoužívám
magické gettery a settery s typovou kontrolou definované pomocí anotací @method – zatím jsem to nepoužil, ale vypadá to užitečně
přístup k reflexi – určitě se hodí – ideálně jako samostatná traita a ty ostatní, které by na ní byly závislé, si jí prostě vyžádají

David Grudl

blindAlley napsal(a):

nové řešení s traitem Strict v latte a dibi se mi nelíbí. Je to celé od začátku do konce o magii, která zásadním způsobem mění chování objektů v php.

Nikoliv, Stict v Latte atd nemění chování objektů v PHP, jen vhodnějším způsobem upozorňuje na logické chyby v kódu (lepší je výjimka než okamžitá smrt na jedné straně nebo mlčení na straně druhé). Výkon v tomto nehraje žádnou roli, stejně jako čtení kódu. Co popisuješ platí pro Nette\Object, ale nikoliv pro Strict.

magické __get, které vrací referenci se mi vůbec nelíbí.

To je technické omezení, které v zásadě ničemu nevadí.

David Grudl

amik napsal(a):

Imho by to tak velký problém být neměl, jedině některé věci budou zřejmě vyžadovat Reflection trait, ale tak si ho prostě vyžádají

Reflection trait je samozřejmě snadno oddělitelný a jak jsem psal, součástí nové traity nebude (tj. bude jen po přechodnou dobu s varováním). Ostatní věci se implementují pomocí stejných magických metod a to prostě oddělit nelze. Respektive netuším jak.

emulovat property: nechci (a to explicitně – přesvědčí mě to třídu/trait celou nepoužít i za cenu obětování dalších funkcionalit)

Pravděpodobně vzniknou dva traity, jeden pro strict a druhý pro strict + event handler + emulaci properties. Nicméně tahle emulace budu vyžadovat, aby na příslušné třídě existovala anotace např. @property $name, takže se nebude moci stát, že by to uživatel použil omylem, jako bylo možné s Nette\Object.

blindAlley

David Grudl napsal(a):

Nikoliv, Stict v Latte atd nemění chování objektů v PHP, jen vhodnějším způsobem upozorňuje na logické chyby v kódu (lepší je výjimka než okamžitá smrt na jedné straně nebo mlčení na straně druhé). Výkon v tomto nehraje žádnou roli, stejně jako čtení kódu. Co popisuješ platí pro Nette\Object, ale nikoliv pro Strict.

Strict nedovolí přidat k objektu libovolnou property, což je bezesporu zásadní zásah do chování objektů v php, nebo se snad v tomhle ohledu v php 7 něco mění? Neříkám že toho kdo ví jak využívám, ale občas se to hodí na různé rychlé prototypování a ověřování hypotéz, se Strict mám smůlu a nemůžu to změnit.
Proč nenechat uživatele vybrat? V tomhle ohledu přicházím o výhodu toho že je to Trait, je mi to např. u komponent nuceno stejně jako předtím Nette\Object.

Pokud i ve Strict zůstane u __get pořád vracení reference, tak jde opět o zásah do chování objektů, normální php objekt žádné reference v __get nevrací a nemůžu to jako uživatel změnit. Imho u strict by vracení reference nemělo být potřeba.

Výkon a čitelnost se Strict netýká, to je pravda, týká se ale properties a ostatního syntax cukru.

Podle mě není důvod nutit závislosti jakýchkoli traits, které nově na základě této diskuse vzniknou, jinde, např. v presenterech a komponentách. Jednoduše nechat uživatele vybrat. Minimálně tedy v další major verzi (3+).

David Grudl

Jak by mělo to vybírání fungovat? Třída buď traitu používá, nebo ne.

Pro potřeby prototypování si lze udělat jednoduchou traitu, která vytváření proměnných naopak umožní. Za předpokladu, že v naprosté většině situací se striktní chování hodí, je lepší, když je třídy mají by default a pokud potřebuju prototypovat, onu „loose“ traitu si přidám do objektu.

trait Loose
{
	function __set($name, $value) { $this->$name = $value; }
}

Proč by normální objekt nemohl v __get vracet reference nevím. Ve většině případů je vracet nepotřebuje, někdy ale ano. Bohužel tohle nelze v rámci dědičnosti měnit, proto se používá ta obecnější z obou možností, tedy reference.

blindAlley

David Grudl napsal(a):

Jak by mělo to vybírání fungovat? Třída buď traitu používá, nebo ne.

Jednoduše u abstract tříd a pak u těch, které se běžně dědí (např. presentery, komponenty, asi celá ta hierarchie komponentového module) trait nedávat. Uživatelé se sami rozhodnou.

Já osobně se strict chováním mám jen negativní zkušenost, setkal jsem s tím jen párkrát a to na produkci, kdy ta výjimka naprosto zbytečně zabila aplikaci, samotné chování PHP s vyhozeným notice by bylo mnohem lepší.

Vracení reference má svá omezení, nejde vrátit null ani objekt přes new a ještě něco dalšího, se pak člověk jen diví, že se to nechová jako normální funkce. Také to může mít vedlejší efekty, mohou se předat reference tam, kde to člověk nepředpokládal a tam se pak hodnota změnit. Přístup použiji reference, co kdyby je někdo potřeboval mě nepřijde v pořádku. Obecně se vracení reference dá podle mě úplně vyhnout, vrátit reference mi přijde jako programovat přes boční efekty a ne čistě.

David Grudl

Řeší se to přes proměnnou:

function & __get()
{
	$var = TRUE;
	return $var; // nebo jen return; pro NULL
}

Tímto způsobem se dá zamezit vrácení reference tam, kde člověk nechce.

blindAlley

Ano, důsledek toho technického omezení, které v zásadě nevadí. Vždycky když na to narazím tak se ptám, proč tohle musím řešit, když žádnou referenci z __get vracet nechci a jsem k tomu nucen nějakou magií pro Strict, která mi párkrát pěkně zavařila.

Abych to shrnul, ukázalo se, že Strict opravdu zasahuje do chování objektů v PHP a jsou situace kdy způsobuje komplikace. Proto nejsem pro jeho další použití ve třídách frameworku, ať si ho použije kdo chce ve svých třídách. Že ostatním se podle všeho strict osvědčil a chtějí ho dál ve frameworku je věc jiná.

David Grudl

Tak prostě nepoužívej Nette\Object nebo Strict. Dědit třídy z Nette a přepisovat jim __get() mi docela zavání.

Filip Procházka

Strict nedovolí přidat k objektu libovolnou property, což je bezesporu zásadní zásah do chování objektů v php, nebo se snad v tomhle ohledu v php 7 něco mění? Neříkám že toho kdo ví jak využívám, ale občas se to hodí na různé rychlé prototypování a ověřování hypotéz, se Strict mám smůlu a nemůžu to změnit.

Napsat property je otázka vteřin, to prostě není argument. Naopak je dobře, že výchozí chování Nette je, že ti brání v tomto prasení.

PHP posledních pár verzí dokáže daleko efektivněji pracovat s třídami, které mají jasně definované properties a žádné dynamické se tam neobjevují a nepřibývají.

amik

David Grudl napsal(a):

Reflection trait je samozřejmě snadno oddělitelný a jak jsem psal, součástí nové traity nebude (tj. bude jen po přechodnou dobu s varováním). Ostatní věci se implementují pomocí stejných magických metod a to prostě oddělit nelze. Respektive netuším jak.

A co vyřešit to větvení __call nějak takhle ? Není to sice úplně nejhezčí, ale drobným workaroundům se stejně člověk při implementaci podobných syntactic sugars nevyhne.
Tohle je jen ukázka principu, jak by se to dalo řešit, Pokud to dává smysl, klidně bych si vzal na starost implementaci.
Jediné, co se mi na tom moc nelíbí a co zatím nevím, jak vyřešit, je nutnost dávat traitu „MultiCallable“ do každé třídy, která implementuje některou z dalších trait, ale s tím by se přinejhorším mohlo dát žít.

Pravděpodobně vzniknou dva traity, jeden pro strict a druhý pro strict + event handler + emulaci properties. Nicméně tahle emulace budu vyžadovat, aby na příslušné třídě existovala anotace např. @property $name, takže se nebude moci stát, že by to uživatel použil omylem, jako bylo možné s Nette\Object.

To bych právě neměl radost :( ta emulace properties by mě nadále odrazovala tu traitu používat, jako mě teď odrazuje používat Object…

David Grudl

Pokud nepotřebuješ properties, tak používej tu první traitu a ne tu druhou.

amik

Tak přinejhorším se to dá :) až teď jsem si všiml, že půjde emulace properties jen v kombinaci @property – to jako pojistka stačí.

David Grudl

Doplním asi ještě traitu pro statickou třídu https://github.com/…07969eb55c39.

amik

Supr, budu jí moct vyhodit z Instante (kde je o 50% jednodušší, jelikož neřeší callStatic) :)

Pavel Kouřil

Osobně se mi nelíbí název StrictPlus – na první pohled to zní to jak kdyby to byla více striktní verze, ale ono to spíš povoluje magii navíc.

Velká škoda je, že to mixování use Strict, Events, ExtensionMethods není možné; osobně bych chtěl používat jen „Events“ a „Strict“, ostatní věci nepotřebuji.

Šaman

s tím StrictPlus souhlasím. Z názvu se nedá odvodit, co vlastně ta traita dělá. Za nejpopisnější, ale moc dlouhý, považuji (Nette)ObjectCompatibility.

David Grudl

Začínám se přiklánět k názoru, že bude lepší použít jednu traitu, tj. sloučit Strict a StrictPlus.

především programátor nemusí přemýšlet, kterou z nich použít
nepřipadá mi cool mít část tříd na Strict a část na StrictPlus v rámci jedné knihovny nebo doplňku
z Nette\Object se bude stejně přecházet na StrictPlus, aby se pomocí varování dalo odhalit a odstranit případné použití jeho původních featur
programátor nemusí přemýšlet, kterou z nich použít (přišlo mi důležité to zopakovat)
vyvolávání událostí přes onEvent() je zcela nekonfliktní syntactic sugar, přitom v Nette hojně používaný, takže spousta programátorů bude stejně raději všude používat StrictPlus
protože když chci vyvolat událost, nechci zkoumat, zda je v dědičné hierarchii použit Strict nebo StrictPlus (jak vůbec?)
nová emulace properties automaticky nefunguje, tj. nic nedělá, dokud nedoplním anotace @property
tedy aktivace properties vyžaduje další krok a je srovnatelné, jestli do kódu doplním @property nebo use Properties. Pokud už takové anotace používám (a nechci emulaci od StrictPlus), tak si stejně píšu svůj __get nebo __set a konflikt nevzniká.
a nakonec: je fakt těžké vymyslet vhodný název pro StrictPlus :-)

Jan Tvrdík

@DavidGrudl Spíš nesouhlasím.

především programátor nemusí přemýšlet, kterou z nich použít

Za mě je to rozhodování docela jednoduché, tam kde jsem používal Nette\Object (typicky aplikace) použiji Nette\Enchantments (mnohem lepší název než StrictPlus), tam kde jsem nepoužíval Nette\Object (typicky knihovny) použiji Nette\Strict.

ani není cool mít část tříd na Strict a část na StrictPlus v rámci jedné knihovny nebo doplňku

To je v podstatě identický problém, jako že teď není cool v rámci jedné knihovny u částí tříd dědit od Nette\Object a u části nikoliv.

nechci zkoumat, zda je v dědičné hierarchii použit Strict nebo StrictPlus

To je v podstatě identický problém, jako že teď musíš zjišťovat, zda třída dědí od Nette\Object nebo nikoliv.

je fakt těžké vymyslet vhodný název pro StrictPlus

Až na to, že sjednocením nic nevyřešíš, protože Nette\Strict je taky debilní název pro třídu, která přidává nové chování jako události nebo handlování @property. Navíc se mi Nette\Enchantments líbí čím dál tím víc.

Šaman

Souhlasím s tím, že pro mě bude zajímavá jen ta Plus. Ale neřeší to jméno, protože Strict stále nic neříká o vyvolávání událostí. A pokud se nebude jmenovat strict, pak je možné pro minimalisty tu strict zachovat taky.
Co SmartObject? Nebo SweetObject (sugar inside)…

Edit: Souhlas s Honzou nademnou. Enchantment se mi docela líbí. Sice se na tom lámou prsty, ale stejně to většinou řeší napovídání.

Editoval Šaman (5. 4. 2016 13:50)

David Grudl

Samozřejmě nikde není ani dáno, že ta jedna traita se musí jmenovat zrovna Nette\Strict. Mně se to líbilo u Texy a Latte, kde skutečně mají jen tu strict funkcionalitu a navíc use Strict; v PHP je boží :-)

Neexistuje ani obecná konvence, jak pojmenovávat traitu, jestli mít TStrict nebo StrictTrait, osobně se spíš kloním k tomu se všech prefixů a postfixů zbavovat.

Může se to jmenovat třeba SmartClass, jednak s tím dovětkem Class to lépe zapadá k StaticClass a není to vázáno na striktnost. Nebo Comfortable, Comfy, ComfyClass …

David Grudl

Jan Tvrdík napsal(a):

To je v podstatě identický problém, jako že teď není cool v rámci jedné knihovny u částí tříd dědit od Nette\Object a u části nikoliv.

Právě. A tohle by se přitom mohlo sjednotit.

Navíc se mi Nette\Enchantments líbí čím dál tím víc.

To nedokáže napsat ani programátor, který už zvládl Environment ;) Takové slovo existuje? ;)

Šaman

Width, height, environment a enchantment. Welcome in HELL :)
Z této perspektivy se mi zatím nejvíc líbí Comfy, ségra od Tracy.

A Strict je možné zachovat pro minimalisty taky. Předpokládám, že každý si vybere jednu variantu a zařadí ji do svého coding standard, takže by k nekonzistenci nemuselo docházet.

Editoval Šaman (5. 4. 2016 14:27)

Jan Tvrdík

@DavidGrudl SmartClass je o hodně lepší než Strict, ale na tak cool jako Enchantments =)

Comfy je super.

A tohle by se přitom mohlo sjednotit.

Obávám se tohle stejně nevyřešíš. Nicméně klidně můžeme zkusit přidat v tom PR jenom Enchantments / SmartClass / Comfy traitu a počkat jak moc budou lidi prskat, že jsi nepřidal i obyčejnou Strict resp. sledovat popularitu Kdyby\Scream.

To nedokáže napsat ani programátor, který zvládl Environment

Nemyslím si, enchantments má fonetičtější spelling, ale samozřejmě ideální na psaní to není. Ještě že existují IDE.

Comfy, ségra od Tracy.

=)

xificurk

A co obyčejné SyntaxSugar?

Pavel Kouřil

Jan Tvrdík napsal(a):

@DavidGrudl SmartClass je o hodně lepší než Strict, ale na tak cool jako Enchantments =)

Vsadím se, že docela dost lidí bude psát Enhancements …

Jiří Nápravník

Pavel Kouřil napsal(a):

Vsadím se, že docela dost lidí bude psát Enhancements …

JJ, ja to tak četl asi třikrát, než jsem si všiml, že tam jsou jinak poskládaná písmenka:)

David Grudl

Tyjo, Comfy je dost úlet…

Co spíš use Comfort.

castamir

Prosil bych neco jednoducheho a uderneho. Neco jako je SmartClass. Na zdrobneliny a slozite pojmy si nevzpomenu, ikdybych to pouzival docela casto a na pomoc IDE se az tak moc spolehat nemohu a nechci (staci jedno spatne pismenko…).

EDIT: a jsem za 2 traity viz prispevek od @JanTvrdík

Editoval castamir (5. 4. 2016 23:35)

xificurk

Comfort prosím ne… ono to má v angličtině trochu jiný (i když částečně se překrývající) význam než by člověk očekával od českého „komfortu“.

http://www.oxforddictionaries.com/…lish/comfort
https://en.wikipedia.org/wiki/Comfort

Editoval xificurk (5. 4. 2016 23:34)

David Grudl

Pull request se zmenou je pripavek k mergnuti https://github.com/…ils/pull/105

Pokud tam chcete neco zmenit, vcetne nazvu, tak to prosim navrhnete jiny:

Zaznělo tu:

Strict
StrictPlus
Comfy
Comfort
Comfortable
Enchantments
SmartObject
SweetObject
SmartClass
SyntaxSugar
StrictEnhanced
StrictButComfortable
Enhanced (Class|Object)?
Improved (Class|Object)?
ObjectClass (do páru ke StaticClass)

Ten název musí být jednoduchý a jasný, slovo Enchantments si asi mnozí museli Googlit a nikdy ho z hlavy nenapíšou, tudy prosím ne.

Proti Strict je oprávněná námitka, že to nevystihuje přidaný syntactic sugar, naopak StrictPlus působí dojmem, že je striktnější než Strict, Comfy je dobrý název pro projekt, ale ne pro traitu nahrazující Nette\Object, to spíš Comfort/Comfortable (je to traita, nikoliv inteface, tak IMHO líp zní use comfort než use comfortable). Slovům jako Cool, Sweet, Sugar a Magic bych se rád vyhnul, působí nevěrohodně.

Namespace

Nette\Comfort nebo Nette\Utils\Comfort?
Nette\StrictClass nebo Nette\Utils\StrictClass?

David Grudl

V diskusi https://gitter.im/nette/nette/cs padlo TStatic, TStrict, TObject