PHP6 - En blick in i framtiden



PHP6 är under utveckling. Det har varit det under ganska lång tid. Redan 11:e november 2005 samlades ett antal av PHP-gruppens tunga namn för att diskutera hur PHP6 skulle se ut. Och hur det i vissa fall INTE ska se ut. Här kan vi ana en viss attitydförändring. Man vill på ett tydligare sätt än innan stimulera (och tvinga) programmerarna att skriva bättre kod.

Många har fortfarande PHP4 på sina servrar, förmodligen av rädsla för att befintliga script inte ska fungera ihop med PHP5. När då PHP6 kommer finns all anledning att tveka, eftersom ännu fler "bakåtkompatibiliteter" tas bort, och vissa beteenden ändras.
Språket PHP kommer i alla fall att utvecklas framåt. Frågan är hur alla de som förvaltar den befintliga kodbasen kommer att ta emot PHP6. Det torde dock inte råda några tvivel om att PHP6 kommer att innebära att programmerarna tvingas skriva snyggare och bättre kod.

Men hur kommer då PHP6 att skilja sig från det vi har nu? Inget av det som står här är på något vis skrivet som något löfte om att det verkligen kommer att bli så när PHP6 kommer, men ur diverse källor på nätet kan man få fram en del om hur det kan tänkas se ut.

Register_globals

Inställningen för register_globals kommer att tas bort helt. Om den finns kvar i konfigurationen kommer PHP inte ens att starta. Register_globals ska vara off. Standardinställningen har varit "off" under längre tid, men gamla script och lata programmerare har krävt att ha möjligheten att slå på globalregistreringen. Och nu... sorry, guys. Nu måste ni lära er att programmera på det säkrare sättet (med $_GET, $_POST etc) till slut.

Och som en direkt konsekvens av borttagandet av register_globals följer att session_register(), session_unregister() och session_is_registered() tas bort. De behövs endast med "register_globals=On".
Status: Implementerat.

Unicode

Uncode-stödet tar mycket resurser i anspråk nu, eftersom det ligger på "request"-nivå. Alla symboltabeller innehåller såväl Unicode- som icke-Unicodenamn, vilket är slösaktigt och inte speciellt effektivt. Man flyttar nu beslutet om Unicode eller ej till servernivå, och lägger in en konfigureringsmöjlighet i php.ini. Att inte kunna stänga av Unicode bedömdes kunna avskräcka från uppgraderingar till PHP6.
För att kunna kompilera PHP krävs att man har biblioteket ICU, och detta oberoende av Unicode är satt on eller off.

Andrei Zmievski, en av PHP-utvecklarna, bloggade den 19:e december 2006 att 1542 av 3084 funktioner nu fungerade, Unicodemässigt. Läs bloggen här

GD1 och Freetype1 tas bort

Stödet för GD1 och FreeType1 kommer att tas bort. Dessa bibliotek är gamla och underhålls inte längre, så PHP-gruppen ansåg att bortplockande av stödet för dessa inte var något problem. De nyare versioner är i alla fall bättre.
Status: Implementerat.

microtime()

Funktionen microtime() ska nu returnera ett "float" som standard. I dagsläget returneras "mikrosekunder unix_timestamp" om inget argument ges till funktionen, och de flesta är nog ändå bara intresserade av att få ett flyttalsvärde.

64-bitars heltal

Ny 64-bitars variabeltyp introduceras.
De heltal som används idag är plattformsberoende, 32 bitar på 32-bitarssystem och 64 bitar på 64-bitarssystem. Att göra om den befintliga heltalsdatatypen till 64 bitar bedömdes vara ett osäkert kort.
Det beslutades att införa en ny datatyp (int64) som alltid är 64 bitar, oavsett plattform.

APC

APC ska bundlas med PHP. Rasmus Lerdorf hade föreslagit att en opcode cache skulle byggas in i PHP. Efter en kort diskussion hade gruppen kommit fram till att den enda tänkbara var APC, på grund av licencieringsvillkoren.
APC inkluderas i PHP-distributionen, men kommer ej att vara aktiverad som standard. Detta på grund av att det krävs lite konfiguration.

register_long_arrays och HTTP_*_VARS

Detta har varit "deprecated" under en tid, och standardinställningen är "off". Superglobalerna $_GET, $_POST etc är bättre och har samma beteende, så det anses inte förorsaka några större problem att ta bort denna inställning.

"Goto"

Programmerare brukar rynka på näsan åt "goto", eftersom det inbjuder till "spagettiprogrammering". Ett alternativt användande av break med en label införs.
Status: Implementerat.

Return by reference

"Return by reference" tas bort.
Kodkonstruktioner som '$foo =& new StdClass()' och 'function &foo' kommer att ge E_STRICT error.

Status: Implementerat.

Hardened PHP patch

allow_url_fopen ska vara enablad
allow_url_include ska vara disablad. Denna inställning kom redan i PHP 5.2.0

ASP-stil

Möjligheten att använda ASP-stilens inledande tagg <% försvinner. Kortformen <? blir kvar, och därmed möjligheten att skriva ut variabler i kort form: <?=$variabelnamn ?> Man kommer inte att införa en kortform för <?php

Safe mode

Safe mode försvinner. Det har motiverats med att begreppet "safe mode" ger fel signaler till användarna, och invaggar dem i en falsk säkerhet.

En ny inställning i php.ini tillkommer: open_basedir_for_include
safe_mode_exec_dir tas ut från safe_mode, och behålles.
E_CORE_ERROR ges ifall safe mode sätts i konfiggen.

dl()

Möjligheten att dynamiskt ladda in PHP-extensioner med funktionen dl begränsas. Funktionen har varit "deprecated" sedan PHP5, och tas nu generellt bort. De SAPI som behöver den är CLI och "embed SAPIs", och där den kommer att finnas kvar men är i övrigt borttagen.

CGI/FastCGI

Implementationen av CGI/FastCGI är rörig. FastCGI är bättre än CGI, men eftersom det kan stängas av ger det rörig kod. Koden ska rensas upp, och FastCGI ska alltid vara aktiverat i CGI SAPI. Det ska inte gå att avaktivera FastCGI.

Snabbare @

Operatorn för undertryckning av varningsmeddelanden, @, ska ses över och snabbas upp.
Inget man som programmerare behöver ta hänsyn till på något sätt, men trevligt i alla fall.

"Var" som alias för "public"

I klasser ska variabeldeklarationer med "var" vara ett alias för "public".
Detta är egentligen inget nytt, för så är det redan från och med PHP5.0.
Man valde att låta PHP5 acceptera "var" som ett alias för "public", men samtidigt protestera lite med en varning E_STRICT. I PHP6 tas denna varning bort.
Status: Implementerat.

Name space

Namespacestöd har diskuterats, vi får väl se hur det blir med det denna gång.
Det råder delade meningar om behovet av detta.
2008-03-02 I den kommande PHP 5.3.0 ska det finnas namespacestöd. Ordet "namespace" är ett reserverat ord från och med 5.3.
Därmed torde vi ha stöd för namespace även i PHP 6.

Magic_quotes tas bort

E_CORE_ERROR ifall magic_quotes, magic_quotes_sybase eller magic_quotes_gpc finns bland inställningarna. Funktionerna get_magic_quotes_gpc() och get_magic_quotes_runtime ändras till att alltid returnera "false".
set_magic_quotes_runtime() medför E_CORE_ERROR.
Status: Implementerat.

zend.ze1_compatibility mode

zend.ze1_compatibility mode tas bort. Det lär inte ha fungerat till 100%, och var en fix för att underlätta migreringen från PHP4 till PHP5. Utvecklarna har nu beslutat att avskaffa denna inställning. E_CORE_ERROR ges om inställningen försöker göras.
Status: Implementerat.

Foreach

Foreach med stöd för multidimensionella arrayer införs.
Exempel:
foreach( $array as $k => list($a, $b))
Funktionsmässigt är detta ingen revolution, det kan implementeras med en extra rad med "list-extrahering" inuti loopen.
Det bedömdes i alla fall som en användbar utvidgning av foreach-syntaxen.

Användandet av {} respektive [] ses över.

Stränghanteringen görs om något med ny funktionalitet liknande substr. Användandet av {} respektive [] ses över. [] ska gälla för strängar.
{} ska ej längre kunna användas för att indexera tecken i strängar. Detta ger E_STRICT från och med PHP5.1, och tas bort helt i PHP6.

[]-operatorn ska för både strängar och arrayer kunna fungera som substr() eller array_slice().
Det ska alltså gå att peka ut ett antal tecken i en sträng, eller ett antal element i en array genom att ange [start, längd]. Dessutom ska strängkonkatenering kunna göras på samma sätt som när element läggs till i en array: $str[]='mer text'.

Konsekvent argumentordning?

Funktionerna in_array() respektive array_search() har dragit på sig klagomål på grund av att dessa använder en inkonsekvent argumentordning, "needle, haystack" där andra funktioner använder "haystack, needle". Det skulle totalsänka många befintliga applikationer ifall detta ändrades, och problemet bedömdes inte vara tillräckligt stort för att motivera en ändring. Så den som retat sig på argumentordningen i de två funktionerna får fortsätta med det ;)

E_STRICT läggs till i E_ALL

E_STRICT (2048) läggs till i E_ALL, och värdet på E_ALL ändras från 2047 till 4095.
Att i E_ALL ha alla felnivåer utom E_STRICT är inkonsekvent, och förvirrande. Genom att som standard även aktivera E_STRICT så kommer dolda programmeringsbrister att komma upp till ytan lättare, och i förlängningen får världen bättre PHP-kod.
2008-03-02 Detta sker redan i PHP 5.3. Dessutom kommer man att skilja på meddelanden om förlegad funktionalitet respektive "fulprogrammering" genom att dela upp nuvarande E_STRICT i två: E_STRICT och E_DEPRECATED.

Reguljära uttryck

Biblioteket ereg är mer eller mindre problematiskt eftersom många väljer att använda andra bibliotek än det som kommer i PHP-distributionen.
Man avser därför göra ereg till en extension, och lägga den i PECL. Istället ska man göra PCRE obligatorisk, och arbeta på att göra PHP-kärnan oberoende av ereg. Regex-biblioteket ska ej bundlas med PHP framöver.

Fileinfo för MIME-detektering

MIME-detekteringen med mime_magic fungerar inte tillfredsställande, och ska ersättas med Fileinfo-extensionen i PECL.
Fileinfo kommer därmed att ingå i kärnan, och alltid vara aktiverad. Extensionen mime_magic flyttar ut till PECL.

Dynamisk break

Stödet för "break $var" tas bort. Det sägs att det inte ens fungerar. Tja, nån som nånsin använt det?
Samma sak för continue med variabel som argument.
Status: Implementerat.

Versaler och gemener

PHP-mötet diskuterade problemet med inkonsekvent hanterande av skift­lägeskänsliga namn.
Medan variabelnamn ska skrivas rätt beträffande versaler och gemener så spelar det ingen roll i funktioner och klassnamn. Att låta PHP först försöka matcha exakt rätt funktionsnamn, och sedan matcha på det "gamla vanliga viset" men ge en varning om funktionen då skulle hittas har diskuterats. Man beslutade att undersöka möjligheterna vidare, men att det i PHP6 inte skulle göras något åt detta.




php6.se ägs av Qualitum Webbhotell