Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 27 reacties
Bron: PHP, submitter: AW_Bos

Het ontwikkelteam van PHP heeft de eerste release candidate van de 5.3.0-tak beschikbaar gesteld. De nieuwe ontwikkelversie van PHP is hier te downloaden en wordt geleverd met een aantal vernieuwingen, die onderaan dit artikel te vinden zijn. PHP noemt zichzelf een 'hypertext preprocessor' en wordt voornamelijk gebruikt om dynamische content in de opmaaktaal html serverside te genereren. De software wordt veelal gebruikt in combinatie met het databaseprogramma MySQL, waarmee de dynamische content van websites en forums kan worden geserveerd. Het changelog van PHP 5.3.0 rc1 ziet er als volgt uit:

The PHP development team is proud to announce the availability of the first release candidate of PHP 5.3.0 (PHP 5.3.0RC1). This release marks the final phase in a major improvement in the 5.X series, which includes a large number of new features, bug fixes and security enhancements.

The key features of the PHP 5.3 branch include:

This release also drops several extensions and unifies usage of internal APIs. Users should be aware of the following known backwards compatibility breaks:

All users of PHP, especially those using earlier PHP 5 releases are advised to test this release as the final release of PHP 5.3.0 will eventually obsolete the 5.2 branch of PHP.

For users upgrading from previous PHP 5 releases there is an upgrading guide available here, detailing the changes between those releases and PHP 5.3.0.

Please also note that we are aware of issues surrounding float/integer handling in some edge cases (some of which have been introduced in PHP 5.2.0), as well as a crash bug in NSAPI, that will be fixed in PHP 5.3.0RC2. These issues however do not prevent wide spread testing of PHP 5.3.0RC1 as users can now rely on the feature set and implementation decisions no longer being changed.

Versienummer:5.3.0 rc1
Releasestatus:Beta
Besturingssystemen:Windows NT, Windows 2000, Linux, BSD, Windows XP, macOS, OS/2, Solaris, UNIX, Windows Server 2003, Windows Vista
Website:PHP
Download:http://qa.php.net/
Licentietype:Freeware
Moderatie-faq Wijzig weergave

Reacties (27)

Zoals telezen is op deze site: http://windows.php.net/qa/

Komt er eindelijk een PHP x64 variant van de windows-binaries :)
Op dit moment helaas alleen nog voor IIS (VC9 compile), voor apache heb je een VC6 compile nodig.

edit: Nu moet ik er even aan denken dat er voor Apache ook nog geen x64 versies zijn (officieel), heeft dus ook weinig zin.. haha.

[Reactie gewijzigd door FlorisB op 26 maart 2009 13:55]

Ik vind nog steeds die namespace separator erg lelijk :') Een backslash, like wtf. Voor de rest is dit wel mooie release, al ben ik steeds meer websites aan het porten naar python, IMO 10x betere taal ;)
Oorspronkelijk werd gewoon (in C++-stijl) :: gebruikt als namespace resolution operator, maar ergens eind 2008 werd dit vervangen door het meest vreemde ooit: '\'

Hierover zijn veel blogposts geschreven, en verder zijn er wel meer vreemd ogende beslissingen gemaakt. Mogelijk toch maar eens hopen op betere ondersteuning voor Python/Ruby op shared hosts, en dat de library-installaties ook vereenvoudigd worden.
Je zou je af gaan vragen wie dat soort beslissingen maakt - wordt dat niet min of meer democratisch gedaan dmv de mailing lijsten oid?
Staat idd op de mailing lijsten.

Men had alle mogelijk keuzes vergelijken, en dat kwam er volgens hun uit als beste. Dat is in feite niet erg lang geleden beslist, aangezien zelf heel wat informatie nog altijd vanuit gaat van :: als operator.

Er zijn heel wat mensen dat deze beslissing zot vinden, maar ja, de php top developers zijn gekend als koppig mensen ;) Moet je een kijken naar zaken zoals:

x( array( 'z' => 'zz' ) ) => x ( 'z' => 'zz' )

Al jaren dat men zaagt voor een named arguments. En toch blijft men koppig dat blokkeren.

$x = array( 'z' => 'zz' ) => $x = [ 'z' => 'zz' ]

Nog zo een leuke. Veel mensen worden het moe om altijd array() te schrijven, terwijl het perfect mogelijk is in de code om [] te implementeren ipv dat je altijd het woord array moet schrijven.

Had zelf iemand een patch geschreven ervoor, getest, en draaide zelf op zijn productie omgeving. Geweigerd...

Grappig is, met die array aanpassing, kan je gewoon een functie gebruiken als:

x( [ 'z' => 'zz' ] );
ipv
x( array( 'z' => 'zz' ) );

Wat een meer named argument structuur opleverde.

Komt vaak voor als iets gevraagd wordt wat een meerwaarde heeft, en dat past niet in de developers hun mindset, zelf als je de aangepaste code aan leverde, dat men blijft weigeren. "Pigheaded"... Niets aan te doen.

Idem met die namespace operator. Hun mening staat vast, en als iedereen in opstand komt, kan hun niet schelen... Iedereen dacht dat het :: ging worden, maar dan kwam men met \

Echt leuk als je zit te programmeren, om dat iedere keer in te geven.
xxx\zzz\sss\aaaaarrrgg
xxx + alt-gr \ + zzz + alt-gr \ + sss + alt-gr \ + aaaaaarrrrgggg

Dat past voor een Querty keyboard, maar een Azerty... fun...

Ik heb persoonlijk mijn twijfel over het gebruik van de namespace... Veel zaken kan je even goed met static & auto include. Denk dat men veel tijd gestopt heeft in iets, dat waarschijnlijk weinig mensen gaan gebruiken. Waartegen simpele zaken zoals die array() => [] aanpassingen, geen tijd kosten, en ja ... Iets dat wel een groot potentieel heeft...
xxx + alt-gr \ + zzz + alt-gr \ + sss + alt-gr \ + aaaaaarrrrgggg
Telkens SHIFT-;-; in moeten drukken in anders ook niet heel comfortabel.

De vergelijking met verschillende types toetsenborden kan ik niet maken, maar op mijn toetsenbord (en ik denk eigenlijk op vrijwel iedere QWERTY) is de backslash een aparte toets. In dat opzicht kan ik me voorstellen dat het wel gemakkelijker typt dan ::.
Er was een heeeeeeeele lange discussie over. En op een gegeven moment hadden de developers op IRC besloten dat ze \ zouden nemen, punt klaar uit geen discussie verder mogelijk.
Soms heb je gewoon iemand nodig die een knoop doorhakt, maar dan nog, ga dan gewoon met de syntax die het bekendst is - :: werkt, een punt zoals in Java (.) is nog korter, etc.
Ik als php-adept ben het met je eens dat python een veel, veel mooiere taal is. Maar bibliotheek gaat boven taal blijkt maar weer eens. Alles wat je wilt kan ontzettend eenvoudig dankzij de honderden bibliotheken. Als taal verliest php, maar op ecosysteem wint php juist weer.

de backslash is ongewoon, maar is onder Windows al bekend als hiėrarchische seperator. Conceptueel is er niets mis mee, het is alleen even wennen denk ik.
De bibliotheek van python is anders ook zeker niet klein (ik zou bijna beweren zelfs groter :o), en makkelijk is het zeker.

Tis alleen nog iets minder ondersteund op webhosts.

[Reactie gewijzigd door Sh4wn op 25 maart 2009 17:40]

Tis alleen nog iets minder ondersteund op webhosts.
En daar heb je net het probleem. PHP kun je belachelijk goedkope hosting voor krijgen, voor Python moet je vaak langer zoeken en de buidel verder open trekken. RoR wordt vaker ondersteund, en voor Java moet je al helemaal ver zoeken.

Ik wil zelf nog eens een webserver hebben, kan ik websites in mijn eigen voorkeur maken :+. Op het moment zou dat nog Java zijn, maar Python moet ik ook nodig uitproberen, en Ruby heb ik wel geprobeerd, maar dankzij een slechte host kon ik die site nooit online krijgen.
Misschien moet je eens kijken naar een VPS (virtual private server). Dan krijg je een VM'etje gedeeld op een echte server. Voordeel is dat je wel gewoon een IP en OS hebt (met root rechten).
Kun je krijgen vanaf ongeveer ¤15 per maand, moet je zelf weten of dat het je waar id
Idd, ik heb zelf ook VPS, maar je moet wel aardig wat RAM hebben wil je beetje fatsoenlijke site kunnen hosten. Meeste VPSjes hebben namelijk geen ondersteuning voor swap.
Precies, PHP heb je vanaf ¤2,50 / maand of soms wel minder. ¤15,- is wel te doen, daar niet om, maar wat krijg je daarvoor? Kun je daarmee 40.000 pageviews / dag afhandelen? (willekeurig cijfer, komt overeen met m'n huidige site op een host voor ¤5,-/maand). Onbeperkte bandbreedte / opslag? CPU limiet?

Ik zou eens op het forum moeten zoeken naar dat soort zaken, ik kan zelf door de bomen het bos niet meer zien, laat staan dat je een goeie vergelijkingssite kan vinden (waarin specifiek staat of er een CPU limiet is en dergelijke, of wat de hoogte van een evt. FUP is)

[Reactie gewijzigd door YopY op 26 maart 2009 10:40]

Omfg hoeveel verschillende mysql extensies zijn er nu wel niet?

Mysql, Mysqli, en nu weer MysqlND ?
Welke is er nou prefered?
MysqlND is de achterliggende library van mysql(i) extensies. Als PHP scripter heb je er vrij weinig mee te maken.
Helaas dat is niet waar. Achter de traditionele libs zit libmysql, mysqlnd is totaal nieuwe c-code. mysqlnd is de nieuwste versie, en zal de beste prestaties gaan bieden. PDO zal er ook gebruik van gaan maken.
Mysqlnd is neither a new PHP extension nor a new API! mysqlnd is new C-level library code. The mysqlnd library provides almost the same functionality as libmysql does. Both C-libraries implement the MySQL communication protocol and can be used to connect to the MySQL Server.

However, libmysql is a generic C-library with Dual-Licensing. Any C-based program can use it. As PHP is based on C, PHP is using it. mysqlnd is not a generic C-library. mysqlnd is licensed under the PHP license and it is tightly integrated into PHP on the C-level. For example, mysqlnd is using the PHP memory management functions and network streams. Due to the close integration, it is difficult for other C programs but PHP to use the library. Any other C program that tries to use mysqlnd would need to link against large parts of PHP. Maybe this explains what “native” and “for PHP” means.

mysqlnd has been designed as a drop-in replacement for libmysql. PHP extensions that use libmysql to connect to MySQL, can be modified to support both libmysql and mysqlnd. This adoption has been finished for ext/mysql and ext/mysqli. Of course, an extension can only use one C-library at a time: either libmysql or mysqlnd. Which one gets used is decided at compile time, see my other blog posting on how to compile mysqlnd.
Dus wat heb je er als php-script mee te maken? de mysql, mysqli en pdo functies blijven hetzelfde dus je hoeft niks aan je scripts te veranderen...
lambdafuncties en closures, wat een heerlijkheid. Functioneel programmeren begint te winnen aan invloed, en terecht.
Namespaces zijn ook mooi, hoewel de huidige werkomheen (de PEAR-stijl) nog aardig te doen is.
doe maar gauw final maken die 5.3, zijn we ook meteen van de recursive object memory leak af!
Uhm... Ik hoop dat je inziet dat het final maken van iets geen bugs fixt? ;-P
Nee, maar het zorgt er wel voor dat hosts die versies gaan installeren (over 20 jaar, misschien, :+ ), zodat ze er zelf ook geen last meer van hebben.
Ik ga de namespaces weinig/niet gebruiken moet ik eerlijk toegeven aangezien ik het toch weer zonde van de tijd vindt. Verder hoop ik dat de "under de hood" perfermance sneller zal lopen. Toch wel jammer dat er een aantal databases verwijderd zijn. Het gebruik zal wel minimaal zijn maar het is toch leuk om soms eens te testen.
Ach het is een kwestie van wennen dat tekentje.
Elke taal heeft wel zo zijn eigennaardigheden.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True