No wlasnie te traitsy dodaja metody w czasie interpretacji kodu?

Tez chcialbym wiedziec co jest nie tak w tym przykladzie...!?!


I to wedlug ciebie jest chore?I psuje kompozycje?Zamiast implementowac ta metode potem w klasie dolaczasz traits-a ktory owa metoda juz posiada...ulatwienie jesli zrobione z glowa!


A co tu jest do podobania sie?Kodzenie to nie widzimisie nie podoba sie to nie uzywasz nie wiem jak uzywac nie uzywasz..dla mnie tez pewne mechanizmy np z python sa dziwne i ich nie uzywam bo poprostu nie widze takiej potrzeby!

Niepotrzebny jest interfejs dla metody, która implementuje traits. Jest to kompletnie nadmiarowe.

Przecież traitsy to jest kompozycja, a nie dziedziczenie.

@wookieb hmm czyli traits sam w sobie dziala jak interfejs dodajac go do klasy wiadomo ze ta bedzie implementowala metoda ktora potrzebujemy dobrze rozumiem?

[PHP] pobierz, plaintext 
class Test {
    use SomeTrait;
}
 
$object = new Test();
$object instanceof Test; // true
$object instanceof SomeTrait: // true
// w takim razie po co interfejs? Nic nie daje a jedynie istnieje "tak sobie".
// W traitsie możesz mieć abstrakcyjne metody = pewien substytut interfejsu
[PHP] pobierz, plaintext 

Jeżeli ktoś znajdzie przykład sensownego zastosowanie interfejsu + traitsów to chętnie zobaczę

@wookieb: Nic nie jest tam nadmiarowe. Jak chcę mieć pewność, że obiekt implementuje interfejs to to jasno określam. A to czy implementacja tego interfejsu jest zrealizowana przy pomocy traitsa, jest odziedziczona czy "normalnie" napisana obchodzi mnie tyle co sytuacja dzieci w Afryce - w ogóle.

Częściowo tak - sam bym poszedł w tę stronę - ale nie do końca. Traitsy w przeciwieństwie do kompozycji umożliwiają Ci transparentne wydzielenie części implementacji. Kompozycja zaś wpływa na interfejs obiektów. Kiedy to się może przydać - sam nie wiem, nie jestem raczej zwolennikiem traitsów, bo w realnym świecie nie za bardzo jest je gdzie zastosować.

Zależy od kontekstu i przeznaczenia. Osobiście nie pchałbym traitsów w takie miejsce.

Właśnie teraz wpadło mi do głowy, że traitsy przede wszystkim mogłyby się przydać właśnie jako takie "code snippety" na kształt tego co pokazałem w przykładzie. Coś w stylu "hej, tutaj masz gotową podstawową implemetnację interfejsu". Miałoby to kilka zalet nad abstrakcyjną klasą robiącą za domyślną implementację.

Swoją drogą sprawdzanie czy obiekt korzysta z traitsa (instanceof) raczej nie ma racji bytu ze względu na fakt, że takim traitesem można manipulować (zmieniać widoczność metod czy ich nazwy). Chyba, że instanceof działałoby wyłącznie z nietkniętym traitsem.

Nie możesz dynamicznie zmienić widoczności metod traitsa ani jego nazw. Takie coś tylko przez ReflectionAPI, które nikt w innych celach niż diagnostyczne/testów nie używa.
A sprawdzanie typu, który jest traitsem ma rację bytu. Przykład w 1 moim poście w tym temacie.

@wookieb: http://php.net/manual/en/language.oop5.traits.php przykłady #5 i #6. Swoją drogą ReflectionAPI używa się poza celami testów - szczególnie, gdy trzeba zadecydować co odpalić na podstawie jakiś danych dostępnych tylko w czasie wykonywania.

Nie zauważyłęm. Przepraszam
Kajam się

Czyli jak mam:

[PHP] pobierz, plaintext 
interface Testowy
{
	public function KuKu(); 
}
 
class Klasa implements Testowy
{
	public function KuKu()
	{
		echo "KuKu";
	}
}
[PHP] pobierz, plaintext 

to będę mógł zapisać tak:

[PHP] pobierz, plaintext 
trait Testowy
{
	public function KuKu()
	{
		echo "KuKu";
	}
}
 
class Klasa
{
	use Testowy;
}
[PHP] pobierz, plaintext 

Ponadto w traitsach mogę deklarować zmienne np.:

[PHP] pobierz, plaintext 
trait Testowy
{
        private $zmienna1;
        private $zmienna2;
        private $zmienna3;
 
	public function KuKu()
	{
		echo "KuKu";
	}
}
[PHP] pobierz, plaintext 

A do tego metoda zaimplementowana w traitsie może być przesłonięta przez metodę w klasie wykorzystującej traitsa?


Przeglądnąłem kody paru blogów (przyznam, że patrzyłem tylko na kod, bo nie chciało mi się czytać, a poza tym nie mam php 5.4 żeby sprawdzić):
http://cogo.wordpress.com/2011/07/01/playi...-php-5-4alpha1/
http://davedevelopment.co.uk/2011/08/06/tr...ging-trait.html
i widzę, że traits może mieć nawet konstruktor:

[PHP] pobierz, plaintext 
trait ParamsHandler {
05	    private $params;
06	 
07	    public function __construct(array $params) {
08	        $this->setParams($params);
09	    }
10	 
11	    public function setParams(array $params) {
12	        $this->params = $params;
13	    }
14	 
15	    public function getParams() {
16	        return $this->params;
17	    }
18	 
19	    public function setParam($key, $value) {
20	        $this->params[$key] = $value;
21	    }
22	 
23	    public function getParam($key) {
24	        return (isset($this->params[$key]) ? $this->params[$key] : null);
25	    }
26	}
[PHP] pobierz, plaintext 

Jakoś mi to przypomina klasę i wielodziedziczenie....

Z tego co sie orientuje to traitsy nie maja konstruktorow i nie mozna utworzyc ich istancji...przynajmniej tak jest w Scali chyba ze w php jest inaczej lub mozna to oszukac za pomoca operator AS -> https://bugs.php.net/bug.php?id=55554