Chciałbym zasięgnąć Waszej opinii na temat przesłaniania metod.
Problem napotkałem w wersji php 6.0.0-DEV (CVS)
Zdaje sobie sprawę, że jest to wersja deweloperska i wszystko w niej może ulec zmianie.

Na początek kod:

[PHP] pobierz, plaintext 
<?php
class A {
 
function test($foo){}
}
 
class B extends A {
 
function test(){}
}
 
$instance=new B();
 
// Fatal error: Declaration of B::test() must be compatible with that of A::test() in (...)
?>
[PHP] pobierz, plaintext 

Oczywiście powyższy kod działa w php 5 poprawnie i nie generuje żadnych błędów.

Zastanawiam się, czy to błąd, niedopracowanie, czy też czeka nas zmiana? Powyższy mechanizm jest dość często stosowany przez programistów. Czy taka zmiana jest logiczna? Macie jakieś pomysły?

Pozdrawiam.

Nie znam się za bardzo na OOP ale może stała protected pomoże ?

Protected niestety nie pomoże. Jedyny przypadek jaki działa, to ustawienie

[PHP] pobierz, plaintext 
<?php
class A {
private function test(){}
}
?>
[PHP] pobierz, plaintext 

Jednak wówczas dla klas potomnych ta metoda w ogóle nie istnieje, więc nie ma czego przesłaniać - jest deklarowana jako nowa metoda.

lista argumentów się nie zgadza

@Ozzy ma rację. Z informacji, które udało mi się wygrzebać w necie (a nie było tego dużo - za wcześnie by podniecać się php 6 ), można nadpisywać metody o takiej samej ilości parametrów. Jeśli ustawisz metodę jako prywatną, wówczas klasa potomna nie będzie mogła się do niej odwoływać i nie będzie konfliktu w parametrach.

Moim marzeniem jest możliwość deklarowania dowolnej ilości metod o takich samych nazwach, lecz różniących się parametrami

Inną ciekawostką, którą znalazłem, jest to, iż utworzenie obiektu B, który dziedziczy po A, spowoduje wywołanie konstruktora z klasy A.

Tak jak jest na przykład w C#, w php bardzo tego brakuje.

Sporo ciekawych rzeczy jest w C# czy Javie. Może w php 7 się znajdą

To żadna nowość, przeciążanie metod jest przecież w c++, więc nie wiem co się tak podniecacie że jest w c# czy javie

Wiem gdzie to występuje. A podniecać się będę, gdy zostanie to wprowadzone do php

Nie zostanie wprowadzone do php póki nie będzie kontroli nad typem zmiennej. Bo co - rozpoznawanie po samej ilości parametrów?

jest kontrola ale nie typow prostych, wiec brak przeciazania funkcji i metod jest conajmniej.. dziwne.

Kontrola typów jest kolejnym "bajerem", którego mi brakuje w php. Czasami, aż krew mnie zalewa, gdy muszę poprawiać jakiś kod, w którym jest zmienna $numer, a w niej jakiś string lub co gorsza array.

Ta nie zostanie nigdy wprowadzone - to jest wlasnie najwieksza sila php, ale dla wielu tez jego bolaczka

Panowie, MySQL nie zostanie nigdy taki jak ORACLE, a php nie bedzie nigdy jak C++ czy Java, dlaczego ? Bo to juz jest. Potrzebujesz cos innego to kozystaj z czegos innego, a nie marudz ze ci brakuje. To jest moze smutna prawda, ale jakże logiczna.
A jesli ktos nie radzi sobie z tym ze jakas zmienna nie jest stringiem tylko np. tablica to ... Aj Karrramba

Pisząc jakąś aplikację w kilka osób nie masz możliwości zapanować nad jej wszystkimi elementami. Widzisz zmienną $number, więc zakładasz, że jest tam wartość liczbowa. Owszem można sprawdzać co tam jest, ale to kolejne wiersze kodu, nie mające nic wspólnego z logiką.



Będę marudził, ponieważ "stronek" nie napiszę w C++. Zaraz ktoś napisze jak to nie? Przecież ten język....... Ale php jest do tego stworzony i nie ma sensu kombinować z innym językiem

Po co zatem interfejsy, metody abstrakcyjne? Przecież to właśnie one w takich sytuacjach sprawdzają się znakomicie.
Taki kod:

[PHP] pobierz, plaintext 
<?php
//class A jak wyżej.
 
class B extends A {
function test(){
parent::test($foo);
//dalsze operacje
}
}
?>
[PHP] pobierz, plaintext 

Daje dość spore możliwości dotyczące np filtracji danych, czy testowania. Wydaje mi się, że wymuszanie powtórzenia argumentów jest zbędne, bo tą rolę pełnią interfejsy.

@batman
Może i wcześnie, ale wolę już teraz pomału przygotowywać aplikacje w php5 tak, aby potem można je w miarę bezboleśnie wdrożyć w php6 Dobrze jest wiedzieć, co może nas spotkać : )

Pozdrawiam.

Aby wiedzieć co się ma w zmiennych używa się dokumentacji - komentowania kodu - i problem znika. Druga sprawa, tablice i obiekty można wymusić, więc pozostają w sumie tylko zmienne "płaskie"

Wersja 6 zmieni się jeszcze tyle razy, że pisanie aplikacji pod kątem niejasnej przeszłości wydaje mi się bez sensu.



A co jeśli w dokumentacji mam napisane, że $number zawiera liczbę, a jakiś programista zostawił mi niespodziankę w postaci tablicy?

Wywalasz wyjątek.
Robisz konwersję do domyślnej wartości, itp.


Jeśli tak bardzo potrzebujesz dorób sobie rozszerzenie do php'a, zmodyfikuj interpreter, albo w ostateczności zrób tak jak ja, czyli napisz własną obsługę przeciążania napisaną jako klasa php (w prostych zastosowaniach jest to dobre, jednak odnotowałem ok. 40% spadek wydajności).


A pomyśl o innym programiście który ogląda taki kod. Krótkie skakanie po interfejsach, wcześniej zapewne po łańczuszku klas rozszerzanych dla zmniejszenia czasu pisania o 5s ( zresztą możesz przekopiować CTRL+C CTRL+V)

Spadek wydajności o 40%? Raczej mało atrakcyjna alternatywa.



I tak robię teraz. Jednak znacznie lepiej byłoby przechwycić wyjątek, niż go wygenerować, a potem przechwycić.

40% to spadek wydajności wywoływania metod przeciążonych w porównaniu do normalnego wywoływania, nie całej aplikacjii.

I tak mało atrakcyjna alternatywa.

W niektórych przypadkach jest to nie do pomyślenia.

To ty sam do swoich metod w swoich klasach przesyłasz złe dane??


Czy ja wiem??
U mnie php jest w stanie w czasie 1s wywołać 200 000 metod typu $obj->method(), a z przeciążaniem 120 000.
Wspomniana metoda jest pusta.

U mnie w dość sporym ( 1MB kodu ) projekcie wywoływań jest ok. 2 500 / request. 90% z tego nie wymaga przeciążania ( gettery i __settery ). Tak więc mam wywołać 250 wolniejszych funkcji, co sprawi że skrypt spowalnia o jakieś 0.000 2 s co jest chyba dopuszczalne.

Napiszę jeszcze raz:
A co jeśli w dokumentacji mam napisane, że $number zawiera liczbę, a jakiś programista zostawił mi niespodziankę w postaci tablicy?



Jeśli piszesz aplikację, która z założenia ma działać "trochę" gorzej niż inne, to już wolę ponarzekać na brak kontroli typów Czasami te ułamki sekund potrafią uzbierać się w spore opóźnienia.

Sorki ze sie czepiam, ale jesli działasz z wieloma deweloperami to raczej trzeba być przygotowany na takie rzeczy ze moze byc jakiś błąd podczas rozwoju i moze byc przekazane dane których sie nie spodziewasz wiec powinienes raczej zrobic tak zebys został o tym powiadomiony a nie zebyc oczekiwał nieoczekiwanego. Oczywiscie ze kontrola typu danych zalatwila by to, ale jesli nie ma tego to trzeba by o to zadbac troche

I tak też robię. Chodzi mi o to, że kontrola typów byłaby doskonałym udogodnieniem.