Witam.
Przeczytałem kilka artykułów dotyczących szóstej wersji PHP i miałbym małe pytanie.
Może najpierw zacznę od tego czego się dowiedziałem.

1. Zlikwidowany zostanie safe_mode
2. Usunięta zostanie dyrektywa register_globals
3. magic_quotes nie będzie już dostępna
4. Z PECL do jądra PHP pofrunie XML Reader oraz XML Writer
5. Z PHP do PECL wyfruną funkcje POSIX (ereg)
6. Standardem staną się wyrażenia regularne PCRE (preg)
7. Zostanie dodane do jądra PHP rozszerzenie Fileinfo, które będzie pozwalać na sprawdzanie formatu pliku (MIME-type), jego rozmiaru itd.
8. Dodadzą instrukcję skoku podobną do instrukcji goto która będzie pozwalała na przeskoczenie do określonego etykietą kawałka kodu
9. Będzie można sprawdzić czy konstruktor klasy macierzystej został wywołany

Dobra teraz moje pytanie.
Słyszałem że zostaną wprowadzone modyfikacje przy przekazywaniu przez referencję i przy tworzeniu obiektu otóż chciałbym się dowiedzieć jakie.

edit>
Podobno zmiana ma dotyczyć zmiennej $this używanej w klasie.

http://snaps.php.net/
ściągnij sobie szóstkę, zainstaluj i sprawdz:D

Initiating objects with the reference operator (& new Object()) will generate E_STRICT error.

Przenoszę z PHP na Hydepark.

Ok dzięki mike.
A co z przekazywaniem przez referencję ?
Czy w metodzie klasy dozwolone będzie coś takiego:

[PHP] pobierz, plaintext 
<?php
class Klasa
{
 var $zmienna;
 function metoda()
 {
   zmien(&$this);
 }
 function wyswietl()
 {
   echo $this->zmienna;
 }
 function ustaw($wartosc)
 {
   $this->zmienna = $wartosc;
 }
}
function zmien($ref)
{
  $ref->ustaw('jakis tekst');
}
$a = new Klasa;
$a->metoda();
$a->wyswietl();
?>
[PHP] pobierz, plaintext 

Chodzi mi o to czy konstrukcja &$this nie będzie wywoływała błędu.
PS. Będzie zwracała konstrukcja =& new Klasa(); błąd bo będzie zwracana zawsze referencja ?
PS2. Dlaczego na Hydepark przecież to PHP dotyczy ?

---
Bo to nie tyczy się rozwiązywaniu jakichś problemów czy dyskusji nad dylematami.
Po prostu sondujesz co ma się pojawić. Ot taka dyskusja.
Tutaj będzie łatwiej ja później znaleźć.
~mike

Masz niestety pewne braki w znajomości php5
Obiekty są zawsze przekazywane przez referencje, więc znaczek & jest nie potrzebny i dlatego będzie powodował błąd E_STRICT.
Słówka var też nie będzie, więc nie stosuj - to jest nawet błąd w php5, choć interpreter nie zgłasza.

Pozdrawiam.

Hehe faktycznie nie wiedziałem albo zapomniałem ( mam nadzieję ),
ale że słówka var nie będzie co oni chcą z tego zrobić Jave ? :/
Jeszcze mnie dobij i powiedz że trzeba będzie stosować też modyfikatory dostępu przed nazwami metod bo też będzie generowało błąd :[
mike: ok przyjąłem rozumiem

Będzie, ale będzie ono aliasem dla modyfikatora public.

Zresztą, oto cała lista zmian: http://wiki.pooteeweet.org/index.php?area=...&page=PhP60
Zmian już wprowadzony, odrzuconych i tych które mogą nadejść.
Sporo jest fajnych ale też sporo idiotycznych, ręce opadają od ich pomysłów.

Będzie jeszcze kilka zmian (np. pełne wsparcie dla Unicode, na które oczekuje najbardziej). Perlowskie RegExy lepsze więc dobrze, że eregi odchodzą do PECLa. register_globals i magic_quotes_gpc - wyfrunięcie tego to będzie zmora dla początkujących programersów, już to widzę - 1/3 stron polegnie z wejścia

Polegnie, nie polegnie, bo zanim szóstka pojawi się na serwerach... Piątka też trochę czekała na rozprzestrzenienie się. Co nie zmienia faktu, że oby jak najszybciej.

@orglee
Ja bym Ci radził przed poznawaniem zmian jakie wniesie wersja 6, przeczytać te co wniosły wersje 5.x, bo widać że masz olbrzymie braki.



No niestety muszę się zgodzić.

> bo zanim szóstka pojawi się na serwerach.
Szóstka nigdy się nie pojawi na serwerach, żaden szanujący się hosting tego nie zainstaluje.
Także tylko dedyki, vps i może serwery "for developer".

Tak jak piątka miała się nigdy nie pojawić i nie wyprzeć czwórki.
Znasz się Ty trochę na temacie, który komentujesz?

> Tak jak piątka miała się nigdy nie pojawić i nie wyprzeć czwórki.
Tego nigdy nie mówiłem.

Różnica pomiędzy wejściem PHP5 i PHP6 jest taka, że PHP6 jest dużo bardziej niebezpieczna dla hostingu, jak i samej strony.
Nie wiem kim jesteś, ale jakbyś był administratorem serwera(dajmy na to 200 klientów) instalowałbyś dziurawe oprogramowanie które może im zaszkodzić?

Ale jak to 6 / 5 niebezpieczna, niby w czym ? Czytałem trochę o atakach na systemy serwerów, które obsługują PHP i wniosek z nich płynął prosty, większość tylnych furtek, to była niedbałość administratorów tychże systemów. Może ci chodzi o to że zabezpieczenie takiego serwera jest kłopotliwe?

@Sędziwoj: No musiałeś dorzucić swoje 2 grosze :/. Dobry rady zawsze w cenie więc ja ci radzę czytać dokładniej. Ja nie jeden artykuł przeczytałem o migracji na piątkę, a jeśli mam jakieś braki to albo śladowe albo po prostu zapomniałem o czymś...

@MarcinP - Nibo co jest dziurawe w wersji 6 ? Konkretne przykłady podaj, bo cos mi się wydaje, że po prostu admini są za leniwi i dlatego taka plotka poszła.

Orglee, Cysiaczek PHP6 jest niebezpieczne w milionie powstałych aplikacji, cały czas użytkowanych.
Nie wiem czy macie dostęp do byłych aplikacji swoich klientów, zobaczcie jak zostały one napisane, zapewniam Cię że jakość kodu i bezpieczeństwa są tragiczne. Co gorsza taki kod jest dalej używany, powielany bo zamiana na nowsze aplikację jest zbyt kosztowna(vide aplikacje bankowe, czy stare systemy dosowe).

Ostatnią furtką bezpieczeństwa były magic quotes którym się mówi papa. Dla tych bardziej zaawansowanych(1% wszystkich kodujących w php?) nie stanowiło to problemu bo sobie poradzili, krzykacze(10%?) uważają że to jest coś strasznego i koniecznie trzeba wywalić, a co z aplikacjami stworzonymi przez 89% osób? One nie są zabezpieczone. Jak zapewne domyślacie się błąd w aplikacji może pozwolić na włamanie się też do serwera, robi się coraz bardziej niebezpiecznie. Czy admini serwera Home, Nazwa, IQ, NQ zainstalują na swoich serwerach PHP6 wiedząc że może to spowodować włamy na strony swoich klientów?

Trochę głupio że developerzy posłuchali krzykaczy.

Fajnie że w PHP6 pojawią się nowe opcje, przydatne, ale programiści PHP już pokazali że nie wiedzą co dalej

Jak przypuszczałem. Brak realnej wiedzy powoduje wygłaszanie śmiesznych argumentów.
Kim jestem? Krzykaczem uważającym że magic_quotes jest złe.

Czy ja dobrze zrozumialem? Ty uwazasz ze dany jezyk (w tym przypadku php) jest niebezpieczny bo ludzie piszą niebezpiecznie? Bo dzieciaki co programuja od dwoch dni i dorwaly sie do php i piszą bzdury i nagle na php6 ich kod bedzie jaki? Bardziej niebezpieczny? No to ich wina a nie php.
Wina php moze byc taka, ze na poczatku pozwalala na takie magic_quotes, register_globals itp. Ale to ze sie z tego wycofują to tylko na korzysc.

edit: biedni klienci co maja strony pisane przez dzieci? No to wina klientow ze dali sobie napisac serwis za 50 zl przez dzieciaka.

ps: sorki za te dzieciaki. nie chce nikogo obrazic z mlodszych userow naszego forum.
zamiast "dzieciaki" niech bedzie: "mniej doswiadczeni programisci"

Zapytam jeszcze raz.

Czy będąc administratorem hostingu zainstalujesz PHP6 wiedząc że duża grupa Twoich klientów posiada nie zabezpieczone strony?

Owszem jako opcję a po ewentualnej konsultacji z klientami na stałe jako główny parser skryptów PHP.
Jeśli natomiast klientów jest dużo to ustawiłbym PHP 6 jako główny parser po roku - dwóch.

Jak dla Ciebie śladowy brak to niewiedza o public/protected/private, że obiekty zawsze są przekazywane przez referencje (mowa o PHP5)... dobra ja teko nie komentuję, każdy sobie sam dopowie.
A "zapomnieć" to można coś czego się nie używa...

Wiadomo, że nikt nie będzie przepisywał aplikacji, jednak ciągle powstają nowe projekty, a bardziej doświadczeni umieją liczyć od 5 w górę. Chcesz zatrzymywać postęp, bo ktoś się pogubi? Moim zdaniem przesada. Przechodziliśmy już przez to przy migracji z 4 na 5. Jeden z jej skutków jest do dziś widoczny na forum - ludzie nie rozumieją podstaw ani oop, ani bezpieczeństwa, ani nawet standardów kodowania. Winne jest wspieranie php4; "bo oscommerce tego używa". Dopiero jakiś czas temu upowszechniło się instalowanie dwóch wersji php i nagle php4 zaczęło znikać.

Osobiście zamierzam nowe projekty pisać (a przynajmniej tak proponować) w zgodzie w PHP6 z wykorzystaniem jego możliwości. Będę podawał wyższe wymagania i tyle.

Pozdrawiam.

--edit
Winą można też obarczyć twórców oprogramowania takiego jak np Krasnal Serv., gdzie główny interpreter to php4 z włączonym register_globals

Gdybym był administratorem zostawiłbym jako domyślny parser PHP5. Parser PHP6 dałbym na przykład dla plików .php6 pozostawiając możliwość wybranym klientom całkowitego przejścia na PHP6.

Z czasem domyślnym parserem stałby się PHP6 a PHP6 byłby na specjalne potrzeby, dla starych skryptów.

Poza tym nie wiem czy wiesz ale możesz sobie manipulować dwoma parserami, wybierając który z nich w której domenie ma być obsługiwany.

Czyli: zrobiłbym dokładnie to samo co działo się przy przejściu z PHP4 na PHP5.

----
Co myślicie na temat całkowitego bojkotu C/C++ i dążenia do unicestwienia tego języka?
Przecież jest ekstremalnie niebezpieczny. Pozwala na złe zarządzanie pamięcią co może zapchać każdy komputer.

Fakt. Tożto diabeł nie język

Co do PHP6 to Wielkie Brawo za wycofanie tych gówien typu magic_quotes tudzież register_globals. ZAWSZE trzeba to wylaczac bo tylko miesza.

Czytając posty MarcinaP wiem już, dlaczego tak opornie wchodził PHP5 na serwery (o zgrozo na niektorych jeszcze jest PHP3 ).
Osoboscie mysle ze PHP6 idzie w dobrym kierunku i niedlugo sie bede na to przestawial (jak narazie piąteczka)

@MarcinP: Wiem ze admini zawsze maja straszne opory przed wprowadzaniem czegokolwiek nowego, pewnie niektorzy jechali by na php3 jesli mozna by było. Ale jak by pomyśleć z drugiej strony, każde nowsze wersje poprawiają wiele błędów, także bezpieczeństwa. Wiec gdzie tu logika ?
Co do wielkich firm hostingowych to tu można by sie zdziwić zapewne. Home z tego co wiem wszystko ładuje w chrooty wiec i miejsce dla php6 sie tam znajdzie.
No i jak koledzy wczesniej mówili. Niebezpieczny nie jest jezyk programowania, tylko użytkownicy którzy z niego kożystają. A pozatym jako admin powinieneś wiedzieć jak zabezpieczyć serwer przed takimi wypadkami.

A co do nowości w php6 to będzie rozszerzenie, a raczej sterownik, mysqlnd czyli natywna obsluga mysql'a. server wykozystuje dwa razy mniej pamieci. Poniewaz dane nie sa trzymane najpierw w buforze przez biblioteke libmysql a pozniej przez ext/mysqli czy pdo w php. Czasy polaczen i zapytan sie troche zmniejszyly.
Ciekawy wpis o mysqlnd
Ale to oraz obsluga Unicode może pojawić się w niedługo wychodzącej wersji PHP5.3, tylko nie jestem pewien czy jako juz w 110% stabilna wersja. Na blogach i w komunikatach ciągle się coś zmienia.

A ja powiem, że zainstaluje PHP6 na serwerze A argumenty w stylu, że oni maja niezabezpieczoną aplikację lub aplikacja nie była pisana pod PHP6 są ... . Ich kod, ich problem Druga rzecz, że admini nie są aż tak źle nastawieni (i leniwi) do nowych rzeczy, jak wam się wydaje Większość zrobi taką rzecz w dość krótkim czasie i dodatkowo zabezpieczy. Inna sprawa, że już od dawien dawna można mieć minimum 2 różne wersje PHP na serwerze to nie widzę problemu, aby tak robić.

Ja nie rozumiem, jaki jest problem z "niebezpieczeństwem" PHP6? Na moim serwerze (tzn. nie moim, ja korzystam z usług ) PHP5 nie jest default (trzeba ustawić poprzez .htaccess), choc niedlugo ma to sie zmienic. To samo będzie z PHP6 - jeśli administratorzy się boją no to można zrobić tak, aby można było włączyć lub wyłączyć. Problem? Nie.

Dokleję się do tematu.

Szukałem trochę informacji...j/w pisało że
magic_quotes_gpc wyfrunie...ale jak mam to rozumieć?
Że nie będzie można tego wyłączyć czy przed cudzysłowami
nie będą dodawane już slashe?

Druga sprawa - stripslashes() - to ma zniknąć?

Tylko patrzeć i się cieszyć że register_globals zniknie

Biega o to, że dane przesyłane do skryptu z formularza nie będą automatycznie przepuszczane przez addslashes(). Funkcje add/stripslashes() pozostana, aczkolwiek sam będziesz musiał sobie dopisać addslashes().

Chyba tylko samobójca opiera zabezpieczeni serwera hostingowego tylko na bezpieczeństwie php. Na porządnie skonfigurowanym serwerze magic_quotes, safe_mode i inne pierdoły są przeważnie wyłączone, bo tylko utrudniają życie ludziom...

a odpowiadając na twoje pytanie: tak, podobnie jak wiele innych osób.

Jako że temat mnie żywo ciekawi włączę się do dyskusji.
Jestem na drugim semestrze informatyki. Możecie powiedzieć że z programowaniem miałem mało do czynienia ale zdołałem się już przekonać że nie da sie stworzyć bezpiecznego języka programowania. Albo język jest zabezpieczony albo jest funkcjonalny i pogodzić się tego nie da. Oczywiście nie można przesadzać ani w jedną ani w drugą stronę. W którymś z kompilatorów (nie pamiętam nazwy) zmienne były oddzielane jedną spacją i wstawienie dwóch wywoływało błąd. Trzeba jednak znać granice między dbałością o programistę a funkcjonalnością.

Czytałem gdzieś (nie wiem czy to prawda) że PHP6 będzie można kompilować. kiedy w PHP jest pętla to kod w pętli jest sprawdzany tyle razy ile wywoływana jest pętla. Taka kompilacja bardzo by przyspieszyła działanie programów. I moje pytanie brzmi czy to jest prawda a jeśli tak czy ktoś mógłby mi to trochę przybliżyć? z góry dziękuje.

Kompilować język, który jest interpretowany linia po linii!?

Te zdania nie mają sensu... tzn, drugie ma... tzn, jest tak oczywiste że ja nie mogę... :/ o co ci chodzi...?

mam sesje jeszcze więc wybaczcie za to jak to napisałem...

Czytałem (prawdopodobnie nie jest to prawda ale ) że PHP6 będzie można kompilować. oprócz tego jakiś kolega mi tak mówił To apropo przyszłości pytanie. A dlatego było by to takie dobre gdyż PHP5 musi sprawdzać kod linia po linii co w przypadku pętli wykonywane jest wielokrotnie. I oto mi chodziło. Ale jak pisałem mam sesje więc wybaczcie proszę.

@down: tak samo jak C#. występuje też coś takiego jak prekompilacja i miałem nadzieję że osoby wypowiadające się tutaj będą tego świadome tak samo jak i tego że każdorazowa procedura sprawdzania poprawności składni ma duży wpływ na szybkość działania programu. jak pisałem studiuje informatyke i wiem na czym kompilacja polega. PHP jest językiem interpretowalnym, zgadza się ale przedewszystkim jest językiem do twożenia aplikacji sieciwych a im szybciej takie aplikacje działają tym lepiej więc to o czym mówie wcale nie jest takie nierealne

Każda wersja PHP sprawdzała kod linia po linii - na tym polega istota języków interpretowanych! Kompilować można języki kompilowane np. C/C++, Pascal itp. a nie interpretowane np. PHP, JavaScript.
Język PHP był, jest i będzie językiem interpretowanym - samą interpretacją zajmuje się tzw. parser.

Ale chrzanicie ...

W silniku Zend'a następuje kompilacja do bytecode'a ... jeśli plik się zmieni następuje rekompilacja do bytecode'a ... skompilowane bytecode'y trzyma w pamięci lub w cache'u na dysku ...

PHP z Exec'ów jest także najpierw kompilowany do bytecode'a a potem wykonywany.

PHP nie jest językiem stricte interpretowanym jak miało to miejsce w przypadku np. basica lub skryptów .bat ...

pozdr.

@Kocurro: Czyli taka jakby Java? Tylko trochę jakby 'mniej' w kazdym kierunku?

No można by powiedzieć Tyle, że w javie ten bytecode możesz otrzymać jawnie a w php'ie aby go otrzymać musisz korzystać np. z eAcceleratora

pozdr.

Widziałem kiedyś kompilator do skryptów bat . Do pythona są jakieś pseudo kompilatory. Ogólnie języki skryptowe są skryptowe nie dlatego, że nie mogą być kompilowane, ale dlatego że nie muszą

A wracając do tematu - nie ma żadnych zapowiedzi odnośnie przerobienia tego phpowego bagienka funkcji na coś bardziej zorientowanego obiektowo? Przydałby się np. Stringa jako obiekt.

Wiesz na upartego każdą zmienną można wsadzić w obiekt i za pomocą metod magicznych wywoływać na nim funkcje odpowiadające typowi zmiennej.
Tylko po co ? Spowolniło by to parser ( lub narzuciło potrzebę przepisania go ). Jeśli PHP ma być zgodne wstecz to musi istnieć możliwość używania proceduralnego stylu programowania. Jeśli na przykład w wersji 7 PHP przeistoczyłby się do języka w pełni obiektowego to specjalnie bym się nie obraził Jednak nie sądzę że taka zmiana jest już zaraz za rogiem i raczej PHP jaki jest taki pozostanie na kilka ładnych lat. --- Oprócz tego nie wydaje mi się żeby taka kolosalna zmiana została zaakceptowana przez wszystkich programistów PHP bo istnieją jeszcze tacy którzy lubią programować proceduralnie.

Zdaje się że na stronie którą podał mike nie ma informacji dotyczących takich niebotycznych zmian. Jak już ktoś powiedział PHP 6 wnosi tylko pewne poprawki kosmetyczne bez rewolucji.

Przestrzenie nazw są pierwszym krokiem do tego typu zmian. Później kto wie ...

I tak wygląda zmiana dużego numerka w przypadku PHP... właściwie mogli już zostać przy 5.x, tylko odrzucić to co powoduje całkowitą niekompatybilność wstecz.