konto usunięte
class A
{
public $x;
}
class B extends A
{
function __set($attr, $value)
{
echo '!!!!';
}
}
$b = new B();
$b->x = 5;
konto usunięte
Rafał Nowak:
Łukasz Karpuć:
Proceduralnie też się da, ale nie o to chodzi, żeby się dało, tylko żeby dało się najprościej i najczyściej jak się da.
Interfejsu nie da się zdefiniować.
To jest zdanie, które najbardziej mnie przekonuje.
Natomiast prawdą jest również, że istnieje wiele zastosowań w PHP, w których rzeczywiście obiekty są pewnego rodzaju strukturami.
Rozumiem argument z rozwojem interfejsu, rozumiem argument z utrzymaniem spójności. Ale skoro coś po prostu jest właściwością, to czy nie wydaje wam się, że _naturalniej_ jest traktować to jako właśnie jako właściwość obiektu?
Może jestem spaczony, ale dla mnie bardziej naturalny jest zapis $user->name niż $user->getName() :)
Wspomniałeś też o wydajności metod magicznych - posiadasz może jakieś materiały na ten temat? Chętnie poczytam.
konto usunięte
Łukasz Karpuć:Nie przeczę, nie neguję a wręcz chwalę i szanuję takie podejście.
Proceduralnie też się da, ale nie o to chodzi, żeby się dało, tylko żeby dało się najprościej i najczyściej jak się da.
Rafał Nowak PIDI.pl
Łukasz Karpuć:
Rafał Nowak:
Rozumiem argument z rozwojem interfejsu, rozumiem argument z utrzymaniem spójności. Ale skoro coś po prostu jest właściwością, to czy nie wydaje wam się, że _naturalniej_ jest traktować to jako właśnie jako właściwość obiektu?
Properties? No można ;) W innych językach.
Może jestem spaczony, ale dla mnie bardziej naturalny jest zapis $user->name niż $user->getName() :)
Bo myślisz strukturalnie, a nie obiektowo ;) Obiekty wykonują operacje. Nie bierzesz gościowi pieniędzy z portfela ($user->money), tylko go o to prosisz ($user->getMoney()).
konto usunięte
Michał Wachowski:
Czy nie lepszym i czytelniejszym zapisem było by
$bar->number = $Array->getValue();
$bar->number = $Decimal->getValue();
$bar->number($Decimal->getValue());
konto usunięte
Rafał Nowak:
No właśnie interesuje mnie tutaj kwestia taka - dlaczego, mimo, że uznajemy paradygmat obiektowy za aktualnie najlepszy jaki wymyślono, inne języki są wyposażone w tego typu rozwiązania?
A, czyli to kwestia uprzejmości? ;-)
Byłbym już całkowicie przekonany do tej idei, gdyby nie to, że skoro i tak chcemy mieć metodę zwracającą nam pieniądze użytkownika to jaka jest różnica w tym, że weźmiemy je jako $user->money,
jeśli w tle możemy wykonać to samo co w getMoney()?
Pokuszę się o stwierdzenie, że to drugie ma jedynie źródła historyczne, a za tym argumentem przemawia obecność Properties w c#, podobne rozwiązania są również w Ruby i Pythonie.
Zawsze traktowałem obiekt jako proste odniesienie do rzeczywistości, a rzeczywiste obiekty nie zawsze po prostu wykonują dla nas czynności, czasem można z nich po prostu odczytać informację o nich samych.
konto usunięte
$bar->setValue( $Decimal->getValue() );
$arr = $bar->getTablica($element);
echo $arr['a']['b'];
konto usunięte
Łukasz Karpuć:
Ale mogą wpływać na to, jak odbierasz ich atrybuty. Biedak może udawać bogatego - nie wszystko jest od razu jasne.
konto usunięte
Michał Wachowski:
Wracając do tematu:
A co powiesz na taki zapis (bo w cytowanym przez ciebie fragmencie strzeliłem gafę)
$bar->setValue( $Decimal->getValue() );
Kilka moich wniosków, na temat czemu warto mieć gettery i settery:
- gettery bo PHP nie umożliwia rzutowania obiektów na cokolwiek innego jak array i string.
- settery bo można zwracać $this i mamy ładne method chaining
class A
{
public $x;
}
class B extends A
{
function __set($attr, $value)
{
echo '!!!!';
}
}
$b = new B();
$b->x = 5;
Rafał Nowak PIDI.pl
Łukasz Karpuć:
Rafał Nowak:
Byłbym już całkowicie przekonany do tej idei, gdyby nie to, że skoro i tak chcemy mieć metodę zwracającą nam pieniądze użytkownika to jaka jest różnica w tym, że weźmiemy je jako $user->money,
Taka, że klasa z której bierzesz kasę ustala w jaki sposób ją Ci da. Może dać Ci 2x więcej kasy, albo nic.
Artur Świerc Programista PHP/Java
public function __set($name, $value)
{
switch ($name)
{
case 'seconds':
$this->seconds = $value;
break;
case 'minutes':
$this->seconds = $value * 60;
break;
case 'hours':
$this->seconds = $value * 3600;
break;
}
}
konto usunięte
Rafał Nowak:
Żeby było jasne - nie kwestionuje idei tego, że klasa powinna wpływać na zwracane dane,
ale moim postulatem była implementacja tego tylko tam gdzie tego potrzebujemy, czyli używanie pól publicznych tak długo, jak nam wystarczają, a jeśli nie wystarczają, zamiana na prywatne i obsługa mutatora/akcesora poprzez __set i __get (jak np. tutaj http://www.php.net/manual/en/language.oop5.overloading... zamiast jego obligatoryjnego pisania i używania.
Wadą tego rozwiązania jest faktyczne pozostawienie rozróżnienia na własności i metody, które, choć jest naturalne, rzeczywiście może nie powinno być podane jawnie. Do wad należy też zaliczyć mniejszą wydajność w przypadku odnoszenia się do pól prywatnych
oraz problemy z czystością interfejsem, kiedy część pól może pozostać publicznych, a część być dostępna przez metody.
Do zalet natomiast można z pewnością zaliczyć brak konieczności pisania dodatkowych metod w klasach, którym wystarcza publiczny dostęp. Przypuszczam też, że korzystanie z pól publicznych tam, gdzie to wystarcza, jest wydajniejsze, niż obligatoryjne wywołanie metody.
konto usunięte
konto usunięte
Michał Wachowski:
I się wszystko wyjaśniło (przynajmniej dla mnie) prócz niebezpieczeństwa protected, bo odesłanie do książki przypomina mi linuchowe RTFM :)
Jeszcze przykład do setterów, jako ciekawostka barzdiej - Symfony2 udostępniło coś na wzór namespace np. $X->set('foo.bar', 'abc'); co w efekcie ustawia $x->arr['foo']['bar'] = 'abc';
I jeszcze kwiatek do __set() - jeden ze znanych mi systemów szablonów, używa __set() do "ukrywania" informacji o braku zmiennej :)
Artur Świerc Programista PHP/Java
Michał Wachowski:
Uczenie czegokolwiek na bazie PHP z wyjątkiem samego PHP jest złe.
Tylko jak człowiek przyjdzie z "normalnego języka" do PHP, to się zdziwi, że mu class A extends B, C nie przejdzie :)Michał Wachowski edytował(a) ten post dnia 12.01.11 o godzinie 23:38
konto usunięte
Artur Świerc:
Wadą php jest to, że na zmiany w języku trzeba czekać zbyt długo. Za dużo tam betonów, którym się nie chce rąk brudzić, wychodzą z zasady "nie ruszać g.. póki nie śmierdzi".
Pomysły są obiecujące, sam czekam m.in. na adnotacje, które w Javie sprawdzają się znakomicie - w innych językach pewnie też. Przy pomocy phpdoc'a to wg mnie bajpas.
konto usunięte
konto usunięte
Michał Wachowski:
Aj karamba - zaspany coś dziś jestem.
Miało być __get() a nie __set w systemie szablonów.
No właśnie, owe niebezpieczeństow, jest względne.
Skoro dajmy na to ja, ustawiłem klasie pola public/protected to widocznie miałem powód i pochodne mają tak mieć. Rzekłem - ja, autor klasy bazowej.
Inna rzecz, związana z niejako z setterami i getterami (skoro już oftopujemy na potęgę) - czyli "rzutowanie" obiektu na tablicę.
Czy $arr = (array) $Obj, czy $arr = $Obj->castArray() ?
Raczej to drugie - bo przy privatach rzutowanie zwraca niezłe śmieci.
$x->a = 5;
$x->setA($b->getValue());
konto usunięte
Następna dyskusja:
пропозиції роботи
