Glupie/smieszne Bledy Oo W Php5 Opcje

[e-Gandalf]

przyklady:

1)

[PHP] pobierz, plaintext 
<?php
 
class Foo {
}
 
function x(Foo $e) {
}
 
$l = new Foo();
 
x((int)$l);
 
?>
[PHP] pobierz, plaintext 

2)

[PHP] pobierz, plaintext 
<?php
 
class Foo {
}
 
function x(Foo $e) {
}
 
x(null);
 
?>
[PHP] pobierz, plaintext 

macie inne? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[hawk]

Zapomniałeś o:

[PHP] pobierz, plaintext 
<?php
 
class Foo {
}
 
$foo = new Foo();
$foo->bar = 1;
echo $foo->bar;
 
?>
[PHP] pobierz, plaintext 

(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[chfast]

2)

[PHP] pobierz, plaintext 
<?php
 
class Foo {
}
 
function x(Foo $e) {
}
 
x(null);
 
?>
[PHP] pobierz, plaintext 

A co w tym jest takiego dziwnego?

[PHP] pobierz, plaintext 
<?php
 $integer = (int) $object;
?>
[PHP] pobierz, plaintext 

Ten kod wcale nie zamienia objektu na integer. Obiekt pozostaje obiektem. Nie wiem co jest odpowiednikiem objektu w liczbach całkowitych (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) ale jakaś cyferka powinna się pojawić.

[e-Gandalf]

1) A moze to, ze w kazdym jezyku swiata kazdy nieprymitywny obiekt (non-primitive object) moze byc dereferencowany (nie wiem jak to tlumaczyc... dereferenced (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ) do nulla? A PHP5 nie pozwala na to?

Dokladnie wycofano do w po php 5 RC3 po JEDNYM mailu jednego z programistow ktory napisal, ze jest to zadko uzywane, a sprawia problemu :/

2) Ja nie proboje zmienic typu, ja przekazuje obiekt zdereferencowany do inta (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) A on to olewa (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[chfast]

Niestety niewiele z tego rozumiem bo nie mam pojęcia, co to znaczy ze obiekt jest 'dereferenced'.

[hawk]

Pomijając derefencowanie (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) chodzi o to że:

1) W każdym normalnym języku obiektowym null można wstawić wszędzie, bo to pusta referencja do obiektu. Np (java):

Kod

Integer i = null

A w php nie. Null nie działa.

2) Rzutowanie obiektu na int jest bez sensu, ale php na to pozwala, a potem olewa całe rzutowanie i robi po swojemu.

Ledwo wydali PHP5 a już wypadałoby zrobić poprawki w silniku...

[e-Gandalf]

Hawk: no dokladnie o to mi chodzilo (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[Dabroz]

Szkoda że nie ma typów danych w php. Można by tworzyć takie cuda jak w C++:

Kod

int a=5;
a.~int();

(IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[edit]

W sumie można to zrobić jeszcze bardziej chamsko (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Kod

4.~int();

(IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował Dabroz 15.09.2004, 16:18:56

[e-Gandalf]

jedziemy dalej:

[PHP] pobierz, plaintext 
<?php
 
class Foo {
  private $password='pass1';
}
 
$foo = new Foo();
 
print_r($foo);
 
?>
[PHP] pobierz, plaintext 

Jak mozna sie latwo domyslic, jest to pierwsza metoda ktorej bym sie imal gdybym mial napisac np. exploita w formie pluginu do jakiegos CMSa, ktory by przechwytywal hasla. buforuje output, wpisuje print_r() przechwytuje regexpem haslo i kasuje bufor. Sliczne. Gratuluje Panom z php.

[hawk]

Komedii ciąg dalszy:

[PHP] pobierz, plaintext 
<?php
 
class Foo {
    private $var;
 
    function __get($sName) {
        return $this->var;
    }
 
    function __set($sName, $mValue) {
        $this->var = $mValue;
    }
}
 
$foo = new Foo();
$foo->bar = &#092;"some text\";
var_dump(empty($foo->bar)); //wynik: true
 
?>
[PHP] pobierz, plaintext 

(IMG:http://forum.php.pl/style_emoticons/default/wacko.gif)

@Gandalf:
Nie potrzeba nawet buforować...

[PHP] pobierz, plaintext 
<?php
file_put_contents(&#092;"ftp://user:password@example.com/pub/file.txt\", serialize($objectWithPrivateVars));
?>
[PHP] pobierz, plaintext 

[e-Gandalf]

poprawcie jesli sie myle, ale to chyba tez blad:

[PHP] pobierz, plaintext 
<?php
 
class Ble {
  protected static $ble=1;
}
 
class Ble2 extends Ble {
  public function foo () {
	print parent::$ble;
  }
}
 
$x = new Ble2();
 
$x->foo();
 
?>
[PHP] pobierz, plaintext 

smieszne, nie?

[hawk]

Dlaczego żenada? Mechanizm jest chyba zrobiony tak, jak powinien być zrobiony. No chyba że kryją się w tym kolejne błędy?

[e-Gandalf]

No, tu niestety ponosimy koszty "kompatybilnosci wstecz". php 5 obsluguje wyjatki, ale samo z nich nie korzysta, wiec otrzymujemy dualnosc jezyka. Nasza funkcja parseFile, fajnie, wywali wyjatek, ale juz fopen() wywali error, a nie wyjatek i oleje nasze try{}. Wyjsciem ktory stosuje w Thotcie jest @. if (!@fopen()) throw new IOException('Could not open file');

[hawk]

Typowy problem języków proceduralno-obiektowych. Tak samo jest np. w C++ i tego nie da się uniknąć. Java to inna sprawa, bo język był obiektowy od samego początku, i ta obiektowość jest "wbudowana" bardzo głęboko. php i C++ - już nie.

[e-Gandalf]

Skoro ten IOException i tak bedzie prowadzil do wyswietlenia informacji i zakonczenia pracy aplikacji moglbys rownie dobrze wrzucic ten msg do exit() a wynik bylby podobny...

Nic mnie nie obchodzi jako autora API co bedzie robil coder z wyjatkiem. On ma go sobie oprogramowac tak jak mu sie podoba. Wazne, ze zwracam mu wyjatek.
Narzut czasowy jest smiesznie niski, bo choc oczywiscie mozemy sie bawic w dyskusje, na czym tracimy ta jedna tysieczna sekundy, to i tak uwazam, ze lepiej to miec i ulatwic czyste programowanie, niz zyskac jedna tysieczna i miec syf.
A potem i tak to jest cachowane (wiekszosc) wiec znika obciazenie, za to o ilez ladniej sie kod pisze (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

A co do Javy - pewnie, ze my tu charujemy, zeby wymyslic cos fajnego z PHP5, nikt nie dyskutuje, ze Java jest lepsza jako jezyk programistyczny (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Tylko, ze w Javie juz wszystko bylo, a php to strasznie nieodkryte poletko, i mozna sie pobawic w innowacyjnosc (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[hawk]

Co prowadzi nas do wniosku że każdą funkcję powinno się dokumentować. Wniosek oczywisty, nawet bez wyjątków i @throws w phpdoc. Oczywiście analizowanie funkcji nie wchodzi w grę.

A co do throws w Javie, to ma to też wady i zdania są, hmm, podzielone. Główna wada była taka, że wyjątek propagował się w górę i to samo działo się z throws, które trzeba było dopisywać do metod które same by tego wyjątku nie rzucały. Skutek: nagromadzenie throws, próby obsługi wyjątku w metodach które nie mają co z nim zrobić lub dziedziczenie z RuntimeException. Chociaż mi throws za bardzo nie przeszkadzało więc rozważania są dosyć akademickie. W każdym razie, zawsze są zady i walety (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .

[netzah]

[PHP] pobierz, plaintext 
<?php
 
class Foo {
  private $password='pass1';
}
 
$foo = new Foo();
 
print_r($foo);
 
?>
[PHP] pobierz, plaintext 

Jak mozna sie latwo domyslic, jest to pierwsza metoda ktorej bym sie imal gdybym mial napisac np. exploita w formie pluginu do jakiegos CMSa, ktory by przechwytywal hasla.

Od kiedy "private" to nie metoda za zapewnianie bezpieczenstwa? Chodzi tu przeciez o wymuszenie na osobach korzystajacych z danych klas uzywania odpowiednich metod zamiast mieszania w zmiennych.
Rownie dobrze moglbym napisac, ze mozna napisac exploita w formie pluginu, ktory zrobi echo $password, bo ktos w tej zmiennej trzyma haslo. Jezeli ma sie system pluginow, trzeba uwazac jakie zmienne przekazuje sie do modulow.

[e-Gandalf]

Poczekaj, poczekaj. Jesli bym chcial zablokowac mieszanie, to wystarczloby odebrac mozliwosc edycji wlasciwosci. Pole typu private blokuje do niego dostep. I to jest cel (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) A to, ze nagle mozna sie do tego pola dostac, to juz cos imho jest nie tak...

[hawk]

1) Taki swodobny dostęp do zmiennych jest rzeczą nietypową. W Javie jest interfejs Serializable i wszystko co z niego dziedziczy można zrzucić do stringa, a potem podejrzeć zawartość. Ale trzeba samemu napisać to implements Serializable.

2) php nie posiada w zasadzie debuggera (no są wyjątki), więc tradycyjnie debuguje się skrypty za pomocą var_dump (fuuuuuj). Debugger musi mieć pełny dostęp do wszystkiego, więc i var_dump musi mieć taki dostęp. Nie da rady inaczej.

3) W php na szczęście ten problem jest mniej dotkliwy, bo i język jest specyficzny. Taki, rzekłbym, chałupniczy. W php nie ma np. żadnego RMI, RPC, CORBY, COM, blah, blah. W php jak piszesz skrypt to jesteś panem i władcą swojego poletka. Nie ma żadnych bibliotek zewnętrznych do których masz tylko interfejs. Nie ma w ogóle zdalnego wywoływania/przekazywania obiektów. Więc małe jest zagrożenie, że autor skryptu musi posługiwać się obiektem, który został stworzony gdzieś indziej.

[netzah]

Poczekaj, poczekaj. Jesli bym chcial zablokowac mieszanie, to wystarczloby odebrac mozliwosc edycji wlasciwosci. Pole typu private blokuje do niego dostep. I to jest cel (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) A to, ze nagle mozna sie do tego pola dostac, to juz cos imho jest nie tak...

Mozna sie dostac do private - nie do konca. Mozna tylko zobaczyc jego wartosc, a i to nie bezposrednio ale przez var_dump itp. Jezeli chodzi o zalozenia private, to uwazam, ze jest OK - nikt chyba, majac obiekt z prywatnymi polami, nie bedzie badac efektow var_dump itp. zamiast uzyc odpowiednich metod dostarczanych przez obiekt. I tak, jak napisal hawk: var_dump, to php-owy debug, kto z Was go czasem nie uzywa? Ulatwia to zycie i wg mnie bezpieczenstwo na tym nie cierpi.


@hawk:
Interfejs Serializable: Jak mogloby to zostac przeniesione do php, zeby nie naruszac zgodnosci z php < 5? Potrzebna bylaby mozliwosc blokowania funkcji serialize() dla wybranych klas, ale wg mnie to zbedne kombinacje, z ktorych nie byloby wielkich korzysci, bo tak jak napisales - zagroznia sa tutaj znikome.