Zrušení properties v Nette\Object

phx napsal(a):

Takova drobnost: pravdepodobne pouzivani properties ma vliv na vykon aplikace. Preci jen se musi vykonat vice radku kodu:))

Tohle mi prijde jako mnohem lepsi argument, nez puvodni litanie.

Ale jak pravi klasicke rceni „premature optimization is root of all evil“.

Já mnohdy také radši použiju getter/setter, ale také nepovažuji existenci této vlastnosti jako významný problém. Nechci-li, nepoužiju ji. Navíc si troufám říct, že přístup k non-public vlastnostem a metodám jiných instancí využívám zřídkakdy. V Javě hlavně u metody equals(Object), kterou mi ale stejně většinou generuje Lombok, v PHP si na takové použití nepamatuji.

22 napsal(a):

Da se uvést příklad, jak taková těžko odhalitelná chyba na základě properties vznikne? Sám jsem se s tím ještě nesetkal, tak abych byl v obraze, abych se s tím nesetkal ani v budoucnu :-)

<?php

class Test extends \Nette\Object
{
	private $name;

	public function getName()
	{
		if (empty($this->name))
		{
			$this->name = necoNajdi();
		}
		return $this->name;
	}

	public function test()
	{
		// není na první pohled zřejmé, jestli chci private proměnnou nebo getName()
		echo isset($this->name) ? "funguje" : "nefunguje";
	}

}

?>

<?php
class TestClass extends \Nette\Object {

	private $prom = 1;

	function getProm() {
		return $this->prom * 100;
	}

	function test(TestClass $obj) {
		return $obj->prom; //tady se nevolá getter
	}
}
$a = new TestClass;
$b = new TestClass;
echo $a->test($b); //vypíše 1, nikoli 100
?>

Properties se snažím nepoužívat. A to ze dvou (vlastně tří čtyř) důvodů:

1. IDE mi nenašeptává vlastnosti, ale gettery a settery ano
2. volání $myClass->property se chová jinak v myClass a jinak venku. Uvnitř třídy stejně musím používat gettery a settery, tak proč to venku psát jinak?
3. ve třídách, které nedědí od NObject se to používat nedá. A pak mám bordel v tom kdy mohu a kdy ne. Třeba tohle $exception->message vyhodí fatálku. (A propo, zdá se mi to, nebo už NObject není taťka všech Nette objektů, ale jen některých?)

Jo a 4. Properties nepodporují fluent rozhraní.

Takže je používám jen v šablonách a jinde je považuji spíš za zdroj problémů.

(Spíš se mi nelíbí, že se toto prezentuje jako cool vlastnost frameworku a přitom to je jenom pozlátko. Pilíře Nette jsou naštěstí jinde. A bohužel, taky jsem toto pozlátko ve svém prvním projektu cpal kam jsem mohl.. ono to k tomu svádí. Holt každý si musí najít svou cestičku k čistým kódům sám. Nechci tím říct, že jsou properties špatné, ale že mému stylu psaní nevyhovují. Supr na nich je, že je v php kódu nemusím používat a v šablonách se hodí.)

@v6ak:

Je to jen příklad s nesmyslnými názvy. Podstatné je, že dostanu objekt, vyvolám na něm property a přesto se getter nevyvolá. Při použití protected, složitějších třídách a více úrovni dědění už se může stát, že si ani neuvědomím, že objekt ($this), může být v hierchii dědičnosti spolu s jiným objektem jiné třídy (mají nějakého společného předka) a má tedy přístup k jeho protected proměnným.

Editoval jasir (4. 10. 2010 13:54)

…NObject od počátku své existence cíleně nabízí a tím je psát properties s velkým prvním písmenem.

Také o tom slyším poprvé. Člověka napadne jako první tohle: $_<property> a jako druhé asi $data[‚<property>‘]. Což je jeden větší hnus než druhej…

To velké písmeno je ovšem geniální… samozřejmě v rámci jistých přednastavených parametrů… :D

Vyhovím tvé žádosti a podporu properties z frameworku skutečně odstraním. Jen to nebude hned. Udělám to s přechodem na verzi PHP, která je nativně zavede. Takže zkuste tlačit tímto směrem.

+1 Přesně tak!

Editoval pekelnik (4. 10. 2010 15:27)

jasir: To je celkem zajímavý argument. Koncepčně je to problém chápání protected v php, ale použitelnost to samozřejmě ovlivňuje.

Já preferuji obvykle spíše méně dědění a více kompozice, ale to neznamená, že Tebou uvedený problém nastat nemůže. (Já navíc properties používám spíše vzácně a rozhodně ne uvnitř třídy, ale to už sem nepatří.)

Nejsem pro rušení properties. I obyčejné plnění šablony v presentru přes $this->template->foo = "" používá magii getTemplate().

1. jasirova ukazka

Ano toto je spravny priklad kedy nastava problem

Edit: Povodne som si neuvedomil preco 2. jasirova ukazka funguje a ziadal som o odkazanie na manual PHP preco to fici, potom som si to vsak lepsie precital a zistil co je vo veci.

Šaman napsal:

Konecne niekto podlozil objektivne dovody preco nepouziva properties!

Je pravda, ze v urcitych pripadoch je treba na properties davat pozor a vediet s cim clovek naraba, ale to je tak aj pri inych sucastiach FW a obecne – je dobre vediet co sa deje pod kapotou a nespoliehat sa na to, ze sa to nejak upatla samo.

Myslim si, ze najvecsia sila properties je v sablonach pripadne nejakych jednoduchych code snipetoch, kde skracuju a sprehladnuju zapis – imho ich primarny ucel.

Editoval westrem (4. 10. 2010 18:47)

Myslím, že používání properties by se třeba v dokumentaci a příkladech nemělo objevovat. Respektive v dokumentaci jen u Nette\Object.

Mě už to nedá a přihodím také do mlýna. Každý rozumný jazyk properties podporuje a tedy argument, že to někdo nemusí znát mi přijde zcela mimo. To byste si mohli stěžovat, že někdo nemusí znát továrničky, Latte filtr, MVC, atd. a tak to všechno z frameworku vyhodíme.

Properties v Nette jsou navrženy velmi pěkně a problém s vyhodnocování viditelnosti proměnných na úrovni tříd místo na úrovni objektů je sice nepříjemný, ale to stačí dát nějaký varovný boxík do dokumentace a nemusíme kvůli tomu rušit či nepoužívat užitečnou featuru. Kolikrát potřebujete v objektu pracovat s jinou instancí stejné třídy? Občas se to stát může, ale moc obvyklé to není. A s potomkem už pracovat mohu bez problému, když bude atribut private.

Celá tahle diskuze mi připadá, že kvůli prkotině chcete zavrhnout moc pěknou vlastnost Nette.

v6ak napsal(a):

Napadá mě, že u .NETu musí řešit vlastně stejný problém, jako napsal jasir ve své první ukázce . Co jsem tak viděl C# zdrojáky, tak prefixují vlastnosti podtržítkem. (Nejsem ze světa .NET a neznám jejich coding standards přesně.)

To jsi viděl nějaký divný C# zdrojáky. Mám za to, že normálně píšou proměnné s malým písmenem na začátku a property s velkým.

jtousek napsal(a):

Pořád tu zůstává podtržítková varianta ala Doctrine. Co je na ní vlastně tak špatného?

Podtržítková varianta ala Doctrine už doplatila na svoji historičnost a mizí.

grey napsal(a):

jak doplatila?

Jak píše Roman B.:

The reasoning is simple: The prefix „_“ is usually either used for easier distinction of instance variables from other, i.e. local variables, instead of always using „this.“ (often seen in C#), or it is used to signal that a member is not meant to be accessed from outside of the class when the language does not have visibility modifiers (PHP4).
Since you always have to use „$this->“ in PHP5+ when accessing instance members and there are visibility modifiers, the „_“ is largely superfluous and just makes the verbose OO code even more verbose.

Editoval Majkl578 (5. 10. 2010 12:54)

Majkl578 napsal(a):

Podtržítková varianta ala Doctrine už doplatila na svoji historičnost a mizí.

Vzhledem k tomu, že je to v Doctrine 2 použité si troufám tvrdit, že to až tak nemizí.

Když se to propojí s Nette properties tak argument že $this->_name namísto $this->name je zbytečné když jsou všechny proměnné stejně private neberu, protože podtržítko by zůstalo POUZE v gettrech, settrech a v deklaraci samotné proměnné. Všude jinde už by se použilo $this->name a automaticky se volaly gettry a settry.

Asi by stačilo dodržovat zásadu o nepoužívání properties uvnitř knihovního kódu, tj. pokud píšete komponentu, nepoužíváte v jejím kódu vlastní properties, zatímco pokud komponentu používáte v aplikaci, využíváte properties dle libosti.

Mám na mysli dobrovolné zásady pro psaní kódu (které používá třeba Nette samotné), nikoliv vynutitelnost. Ta by představovala řádově větší magii. Pravidla pro používání properties musí zůstat jednoduchá.