Otóż mam sobie metodę klasy Member:

[PHP] pobierz, plaintext 
<?php
/**
 * Finds a row by specified key
 *
 * @param string $key
 * @return Zend_Db_Table_Row|null
 * @author Michal Plachta
 **/
public function findByKey( string $key )
{
	return $this->fetchRow( array( 'key = ?' => $key ) );
}
?>
[PHP] pobierz, plaintext 

Wywołuję ją w sposób następujący:

[PHP] pobierz, plaintext 
<?php
$member = new Member;
$current = $member->findByKey( $key );
?>
[PHP] pobierz, plaintext 

I co dostaję?


I gdzie tu logika? Dodam tylko, że analogiczna sytuacja dla typu array działa.
Daję na Hydepark, bo nie jest to dla mnie problem nie do rozwiązania. Traktuję to raczej jako ciekawostkę. Jak ktoś uzna, że trzeba przenieść, niech przeniesie.

ROTFL

seaquest wstiiid

Narzucać typ można tylko bool i array() w innym wypadku narzucasz interfejs lub konkretną instancję

@seaquest: no bo to jest logika php. Możesz wymuszać argumenty tylko instancji jakiś klas/implementacji interfejsów. No a typy "atomic" (atomowe?) to nie klasy. Oczywiście z wyjątkie bool i array, które też najwyraźniej są klasami. LOL. To się nazywa niepełna obiektowość oraz niespójność czy też niekonsekwencja. Aha - mój LOL odnosi się do PHP, nie do Twojego postu .

No właśnie, ja się nie wstydzę.
To jest niekonsekwencja języka. Wina jego twórców. Jeżeli robi się coś, to się powinno zrobić to do końca. A nie w taki sposób.

Wiem, że ta sytuacja jest opisana w manualu, ale nie powinno być tak, że to język zmusza mnie do zaglądania w manual.
No i popatrzcie jeszcze na komunikat błedu. Sam komunikat nie mówi nic, a już on powinien mi powiedzieć, że tego nie można stosować do typów prostych (poza bool i array).

Do tego wymuszenie typu array jest dodane od 5.1 więc jeszcze bardziej komplikuje.
Co do logiki, to ja w nią powątpiewam przy PHP, bo tu nie zrobili czegoś do końca, ale np. jest rozszerzenie PECL do przeciążania operatorów, czemu jego by nie dodali do standardu, przecież to by było bardzo przydatne.
Czy opieszałość z zakończeniem rozwoju poprzedniej wersji (chodzi o 4), czy za szybkie wprowadzenie 6, bo zmiany jak na zmianę głównego numerka nie są takie duże. Powinni całkowicie przebudować język, pozamykać wszystkie funkcje w obiekty, i parę innych rzeczy... ale to może moje zdanie.

Moim skromnym zdaniem można się jedynie przyczepić komunikatu. Nie od dziś wiadomo, że php nie rozpoznaje w argumentach typów prostych/atomowych/prymitywnych - jedynie typy złożone. Nie rozumiem jednak problemu, któ¶y przedstawiasz... zaglądać do manuala? Po co? Skoro możliwe są tylko array i object, to jeśli nie jest tam napisane array, to znaczy, że ten ciąg znaków przed nazwą zmiennej odnosi się do jakiegoś obiektu - to jest logiczne. Tym bardziej, że w php nie będzie nigdy możliwości wymuszena argumentu funkcji, Inna rzecz - typ zwracany, którego brak jest skandalem. Kończę, bo temat argumentów jest poruszany w wielu innych topikach.

Pozdrawiam.

@Cysiaczek
Nakieruj mnie na dyskusję o sprawdzaniu typów przekazywanych (chodzi o podstawowe).
Bo ja jakoś nie widzę sensu wprowadzać typizacje wartości zwracanej, a nie zrobić to dla przyjmowanej. Najwyżej dodać domyślny typ, tak lubiany "mix".
A przy określaniu typów przyjmowanych można by było poprawić obiektowość, przeciążenie.

Stricte dyskusj to ja nie widziałem - powtarzam tylko słowa developerów, którzy przy okazji komentowania próśb o wymuszanie typów argumentów powiedzieli, że jest to niezgodne z ideą php.
Co do typów wartości zwracanych - nie zgadzam się, że nie ma sensu przy braku takiego samego mechanizmu przy argumentach. Wywołujący funkcję (użytkownik kodu) musi zadbac o poprawne argumenty, ale już to, co otrzyma niekoniecznie musi mu odpowiadać. Dam taki przykład:

[PHP] pobierz, plaintext 
<?php
class someData
{
	function getData($bool=false)
	{
		if($bool)
		{
			return new dataObject();
		}
		else
		{
			return array("no", "data");
		}
 
	}
}
$obj=new someData()
$data=$obj->getData();
// i teraz nastepują testy
	if(is_array($data)){}
	  elseif(is_object($data)){}
?>
[PHP] pobierz, plaintext 

Gdyby metoda getData() miała ustalony typ wartości zwracanej, to testy niebyłyby potrzebne. Odpowiedzialnośc spadłaby na metodę getData(), która musiałaby zwracać np. tablicę.

[PHP] pobierz, plaintext 
<?php
function Array getData($bool=false)
	{
		if($bool)
		{
			$obj=new dataObject();
			return $obj->getAsAray(); //albo jak kto tam chce
		}
		else
		{
			return array("no", "data");
		}
 
	}
?>
[PHP] pobierz, plaintext 

Niweluje to trochę zamętu w kodzie. Ja czasami piszę tak, jakby oba obiekty były umówione co do typu, ale to utrudnia wysledzenie błędu, bo musze go szukać w dwóch obiektach. Omijam zatem testowanie, co może się odbić czkawką przy późniejszyxch zmianach. Gdyby dali mi możliwość wymuszenia typu - od razu miałbym błąd i nie musiałbym odtwarzać procesu, który do niego doprowadził. Tak się dzieje najczęsciej, gdy zwrócona wartość nie wpływa bezpośrednio na kod użytkownika, ale jest jedynie zapamiętana i wykorzystana w jakimś odległym miejscu, albo (o zgrozo!) zapisana.

Pozdrawiam.

Raczej powinieneś robić:

[PHP] pobierz, plaintext 
<?php
function array getData( $bool = false ){ 
		if( !is_bool($bool) ){
			throw new Exception( 'Błędny parametr' );
		}
		if( $bool ){
			$obj = new dataObject();
			return $obj->getAsAray(); //albo jak kto tam chce
		}else{
			return array( "no", "data" );
		}
 
	}
?>
[PHP] pobierz, plaintext 

I znów gdybyś miał sprawdzanie typu przekazywanego, byś mógł pomijać fragmenty sprawdzający typ.
Co do "niezgodne z ideą php" dobre poglądy ulegają rewizji, a nie biernie istnieją.
Ale ja nie lubię wdawać się w ideologiczne gadki, bo to nie ma sensu, język powinien być praktyczny nie zgodny z jakąś ideologią.

Nie chodziło mi o argumenty, a o różne wartości zwracane przez metodę.

Rzeczywiście - jeśli to jest kwestia ideoogii, to faktycznie jest to bzdura, ale jeśli za tym stoją jakieś bardziej merytoryczne przesłanki, to nie pozostaje nic innego jak przyjąc do wiadomości zdanie "nie da się" : )
Z drugiej strony nie bardzi rozumiem, że dało się wymusić arraya, a nie da się typów prostych. Założę się, że devom nie chce się przepisywać od nowa większości funkcji języka, co niechybnie po takim zabiegu byłoby konieczne, albo przeważyły względy wydajnościowe.

Pozdrawiam.

I tak musi sprawdzać co przekazuje, czy musi sprawdzać, bo raz musi czy to jest obiekt lub array, a raz nie bo typ podstawowy.
I też nie mówię aby było to w 5, ale 6, gdzie mogli by to dodać, tak jak z PECL "operators" (co już pisałem) bo wtedy to już były by niezłe możliwości.
A chyba doskonale wiesz, że nie ma tak że się czegoś nie da, tylko trzeba się narobić...

@Cysiaczek
ale zobaczy na cos takiego jak jest w propelu, gdzie np. metoda retriveByPk zwraca obiekt modelu wyszukany po kluczu głównym, a jeśli nie znajdzie nic to zwraca null
i tak mamy:

[PHP] pobierz, plaintext 
<?php
$objUser = UserPeer::retriveByPk( 1 );
if ( ! $objUser ) {
return $this->forward404(); //nie ma obiektu - nie ma strony...
}
//działamu na obiekcie
?>
[PHP] pobierz, plaintext 

zamiast:

[PHP] pobierz, plaintext 
<?php
try {
$objUser = UserPeer::retriveByPk( 1 );
//działamu na obiekcie
}
catch ( Exception $e ) {
return $this->forward404(); //nie ma obiektu - nie ma strony...
}
?>
[PHP] pobierz, plaintext 

co nie jest moim zdaniem wygodniejsze...

ale mimo wszystko wolałbym wszystko jawnie typowane jak w javie...

Brak typowania (zarówno wejścia jak i wyjścia) to jest coś co mnie osobiście strasznie drażni w php. Czasami jak mam funkcję, która może przyjmować kilka różnych parametrów i do tego w różnych zestawach - np. raz 2 inty innym razem 1 obiekt itp, to po kilku dniach sam nie mogę się połapać w if'ach jakich użyłem żeby to wszystko sprawdzić.
Typowanie + przeciążenia bardzo by się przydały. Dla kompatybilności wstecz można by zostawić tak jak ktoś wspominał wartość domyślną w funkcji mix i tyle. Wtedy i wilk byłby syty i owca cała. Kontrola typu zwracanego to krok w dobrą stronę, ale jeśli musiałbym wybierać, to wolę kontrolę typów na wejściu niż wyjściu.

Ale najbardziej w tej całej sytuacji denerwuje mnie tłumaczenie, które pojawia się we wszystkich informacjach na ten temat - typowanie jest nie zgodne z ideą... Co to za argument... Może warto podać coś bardziej merytorycznego... albo chociaż powiedzieć w prost, że w chwili obecnej nie ma kto tego zrobić, bo jest za mało ludzi. Chyba trudno spotkać programistę php, który nie chciałby typowania w php więc zasłanianie się ideą php jest co najmniej śmieszne.

No cóż może za 5-6 lat jak wyjdzie php7 to ktoś to przemyśli i poprawi.

Dynamiczne typy zawsze były zaletą PHP'a... Zmieńcie język jeśli to wam nie odpowiada. Java/c# stoją otworem przed wami.

Nie mam zamiaru porzucać php ponieważ z mojej perspektywy ten język ma wiele zalet: jest darmowy, ma duże wsparcie społeczności, jest łatwy, idealnie sprawdza się w zastosowaniach, dla których go stosuje itd. Dynamiczne typowanie... ok to rozumiem - osobiście nie lubię, ale rozumiem, że ma to swoje wady i zalety.
Ale z drugiej strony nie widzę powodu, dla którego nie stosować w funkcjach wymuszania typu na życzenie + przeciążeń funkcji - mechanizmy te są bardzo przydatne, co zresztą widać po głosach prawie całej społeczności, która się tego domaga.
Myślę, że php bazuje na swojej społeczności więc społeczność ma prawo wskazywać pożądane kierunki rozwoju tego języka.

My się domagamy, bo robimy coś "więcej" niż PHP ("personal home page" czy jak to szło) ale przecież to co napisałem możliwość, czyli jak jest bez wymuszenia (czyli jak teraz bez nazwy klasy czy array) wtedy przyjmuje co dusza zapragnie, ale dać możliwość wymuszenia typu podstawowego, czy to int, string itd. Bo tak jak się chce być pewnym co się dostaje trzeba samemu sprawdzać typ... Typ zwracany jest również przydatny, bo wiadomo co na pewno zwróci, a wyjątki są w przeciwnym wypadku.
Do tego przy wymuszonych typach argumentów pojawia się przeciążenie, a to ułatwia czytanie kodu, bez zawiłych if'ów, zwiększa czytelność.

Trzeba pamiętać, że reprezentujemy raczej grupę tych bardziej zaawansowanych programistów PHP, więc musimy też pamiętać o początkujących, a jak widać nawet w dziale PHP (nie początkujących) większość nawet brak typizacji niewiele ułatwia, więc dla nich wymuszone typy, przeciążenia, ba przeciążenia to coś już zupełnie abstrakcyjnego dla nich klasy i obiekty to coś na granicy zrozumienia (tak jak dla każdego który nie miał wcześniej styczności, pamiętam jak 4 lata temu tworzyłem pierwszą klasę, bo wszyscy mówili jakie to oh i ah, ale jakoś nie pojąłem idei, teraz się z tego śmieję ) więc dla nich też trzeba zostawić furtkę. Bo PHP dzięki temu zyskał popularność, ale musi się też rozwijać.

ale przeciążanie jak i typowanie byłoby imo opcjonalne, chcesz używaj nie chcesz pozostaw aby można było typowac dynamicznie i wtedy wilk syty i owca cała ;p

Tylko, że i tak php musiałoby sprawdzać typ zmiennej, a to duży ma wpływ na wydajność.

--edit
To jest język interpretowany - w kompilowanych jest szybciej i nie widać takiego spadku wydajności, a tu moze być widoczny.

Spytam, co Ty [cenzura], i tak musi sprawdzać czy to obiekt tego typu, czy to array, więc nie widzę gdzie ten Twój argument, bo chyba nie powiesz że sprawdzenie typu podstawowego jest droższe od sprawdzenia typu obiektu.

----

hola
revyag