PHP7, nieuwe features

[HollowGamer]

Sinds deze week zit PHP 7 in de Arch repo, ben ik aan de slag gegaan met aantal nieuwe features.
Wel zijn er voor mij een paar verwarrend, vandaar dit topic.

De nieuwe namespace parameters ontzettend handig, zo kun je nu meerdere sub-namespaces definiëren:

PHP:

Namespace\{sub,sub}

Verder zijn de type declarations eindelijk toegevoegd.

Deze nieuwe feature vind ik wat vreemd:

PHP:

$v = $x ?? $z;

Dit wordt gedaan d.m.v. een isset, terwijl ik een empty() logischer zou vinden. Helaas kun je dit niet doen:

PHP:

$v = !empty($x) ?? $z;

Dan krijg je volgensmij empty op een isset?
Waarom empty? Dat is gezet is, wil nog niet zeggen dat het 'gevuld' is. Als voorbeeld op PHP.net wordt een $_GET gebruikt, en die wil je juist (in de meeste gevallen) niet leeg hebben.

Alleen merk ik wel op dat ik de PHP manual altijd zo cryptisch vind, en altijd ergens anders (op een blog/SO) moet kijken om te zien hoe ze echt bedoelen (praktijkvoorbeelden).

Ik heb dan ook de vraag of we de nieuwe functies wat verder zouden kunnen laten zien.

[ Voor 29% gewijzigd door HollowGamer op 05-01-2016 14:24 ]

[CH4OS]

empty() is anders dan isset(), isset() checked namelijk of de variabele $var bestaat én niet null is, waar empty() checked of $var null of false is. Voor empty() móet de $var dus bestaan, waar dat voor isset() niet per se hoeft te zijn.

[ Voor 17% gewijzigd door CH4OS op 05-01-2016 13:49 ]

[Voutloos]

HollowGamer schreef op dinsdag 05 januari 2016 @ 13:29:

PHP:

function method(string $k, string $v = '')

Dit geeft een fout als $v leeg is, i.p.v. daarvan moet ik zeggen $v = null. Ligt dit aan mij of heb ik dit mij fout aangeleerd?

Dit mag trouwens ook niet: bool $v = false, dit moet zijn:

PHP:

bool $v = null

Welke foutmelding krijg je precies?

Zie https://3v4l.org/Kn9lE , dit werkt gewoon prima. Als je de melding 'Fatal error: Default value for parameters with a class type hint can only be NULL' krijgt gebruik je eenvoudigweg nog geen PHP7.

[InZane]

Lamaar..

[ Voor 97% gewijzigd door InZane op 05-01-2016 13:51 ]

[CH4OS]

TS bedoelt daar, dat je de bool $v wél een null kan meegeven (wat even goed een false geeft in checks) en dus niet écht false kan meegeven.

EDIT:
Stiekem weghalen hé...

[ Voor 11% gewijzigd door CH4OS op 05-01-2016 14:00 ]

[HollowGamer]

CptChaos schreef op dinsdag 05 januari 2016 @ 13:35:
empty() is anders dan isset(), isset() checked namelijk of de variabele $var bestaat én niet null is, waar empty() checked of $var null of false is. Voor empty() móet de $var dus bestaan, waar dat voor isset() niet per se hoeft te zijn.

Check dit voorbeeld: https://3v4l.org/dnMfl
Hierbij kan ik dus een $_GET doen, die leeg is, waardoor je dus nog extra moeten checken of deze is gevuld. Dit moet je trouwens altijd controleren, maar het is maar als voorbeeld.

Voutloos schreef op dinsdag 05 januari 2016 @ 13:36:
[...]
Welke foutmelding krijg je precies?

Zie https://3v4l.org/Kn9lE , dit werkt gewoon prima. Als je de melding 'Fatal error: Default value for parameters with a class type hint can only be NULL' krijgt gebruik je eenvoudigweg nog geen PHP7.

Ik word gek..
Gisteren bleef ik maar foutmeldingen krijgen, misschien was er nog iets gecached?
Al weet ik zeker dat ik nginx, php-fpm, etc. allemaal heb gerestart.

Ik zal het nog een keer proberen, misschien komt door fout door iets anders.

CptChaos schreef op dinsdag 05 januari 2016 @ 13:51:
TS bedoelt daar, dat je de bool $v wél een null kan meegeven (wat even goed een false geeft in checks) en dus niet écht false kan meegeven.

EDIT:
Stiekem weghalen hé...

.. Inmiddels werkt dit ook weer.
Ik heb waarschijnlijk iets fout gedaan, of mijn instellingen in php.ini staan verkeerd (ben wel begonnen met een schoon copy).

[Voutloos]

HollowGamer schreef op dinsdag 05 januari 2016 @ 14:20:

Ik word gek..
Gisteren bleef ik maar foutmeldingen krijgen, misschien was er nog iets gecached?
Al weet ik zeker dat ik nginx, php-fpm, etc. allemaal heb gerestart.

Ik zal het nog een keer proberen, misschien komt door fout door iets anders.

Je bent gewoon een herstart vergeten, of zat op meerdere servers te werken etc. etc. Overkomt ons allemaal wel eens.

[CH4OS]

HollowGamer schreef op dinsdag 05 januari 2016 @ 14:20:
Check dit voorbeeld: https://3v4l.org/dnMfl
Hierbij kan ik dus een $_GET doen, die leeg is, waardoor je dus nog extra moeten checken of deze is gevuld. Dit moet je trouwens altijd controleren, maar het is maar als voorbeeld.

Ik begrijp werkelijk waar niet wat je nu wilt zeggen, de code doet toch precies wat je vraagt? Je wilt het tegenovergestelde van true, die var_dump je vervolgens, dan is het toch niet raar dat je false er uit krijgt?

[ Voor 20% gewijzigd door CH4OS op 05-01-2016 18:22 ]

[HollowGamer]

Voutloos schreef op dinsdag 05 januari 2016 @ 14:59:
[...]
Je bent gewoon een herstart vergeten, of zat op meerdere servers te werken etc. etc. Overkomt ons allemaal wel eens.

Denk inderdaad dat dit het geval is.
De volgende keer doe ik nogmaals een test.

CptChaos schreef op dinsdag 05 januari 2016 @ 18:18:
[...]
Ik begrijp werkelijk waar niet wat je nu wilt zeggen, de code doet toch precies wat je vraagt? Je wilt het tegenovergestelde van true, die var_dump je vervolgens, dan is het toch niet raar dat je false er uit krijgt?

Ik bedoel iets anders, stel je hebt het volgende (niet het beste, maar is als voorbeeld:

[php]
// url=http://example.com?q=
$v = !empty($_GET['q']) ? $_GET['q'] : $var;
[/[php]

Dan krijg ik met de bovenstaande dus $var, maar met deze nieuw feature:

PHP:

$v = $_GET['q'] ?? $var;

Is $_GET['q'] inderdaad gezet, maar nog altijd leeg, dus krijg ik $_GET['q'].
Vandaar dat mijn vraag is of het niet logischer zou zijn dat er voor een empty() was gekozen, i.p.v. een isset().
Bij het voorbeeld wat zij zelf gegeven, lijkt mij dat logischer, je wilt toch checken of q=zoekterm(en) is en dus is ingevuld?
Nu doe je altijd valideren, maar een empty if juist handig dat je kan controleren dat het bestaat en een waarde heeft.

[CH4OS]

Dan gebruik je dus géén empty(), maar isset(). Die doet namelijk precies wat jij wilt!
Zie CptChaos in "PHP7, nieuwe features".

Dat geeft dan dus

PHP:

if(isset($_GET['q'])){
    //
}

[ Voor 51% gewijzigd door CH4OS op 05-01-2016 19:05 ]

[Voutloos]

Of gewoon '?:' sinds PHP 5.3 https://3v4l.org/e2UYA

[HollowGamer]

Voutloos schreef op dinsdag 05 januari 2016 @ 21:05:
Of gewoon '?:' sinds PHP 5.3 https://3v4l.org/e2UYA

Dat is precies wat ik zocht.. heb ik daar alle tijd overheen gekeken.

CptChaos schreef op dinsdag 05 januari 2016 @ 19:03:
Dan gebruik je dus géén empty(), maar isset(). Die doet namelijk precies wat jij wilt!
Zie CptChaos in "PHP7, nieuwe features".

Dat geeft dan dus

PHP:

if(isset($_GET['q'])){
    //
}

Dat is niet wat ik bedoelde.
Ik bedoelde dat er een empty beter was in mijn optiek, maar Voutloos heeft mij laten zien dat 'ie wel degelijk bestaat.

[Ruubster]

CptChaos schreef op dinsdag 05 januari 2016 @ 13:35:
empty() is anders dan isset(), isset() checked namelijk of de variabele $var bestaat én niet null is, waar empty() checked of $var null of false is. Voor empty() móet de $var dus bestaan, waar dat voor isset() niet per se hoeft te zijn.

Volgens mij klopt het niet wat je zegt, empty() geeft ook FALSE terug als de var niet bestaat. De var hoeft dus niet te bestaan, ook volgens de docs niet:

A variable is considered empty if it does not exist or if its value equals FALSE. empty() does not generate a warning if the variable does not exist.

Ik vind het wel een vreemde functie, want 0 is dus leeg, 0.0 is leeg, maar 0.00 niet. Heeft me al een paar keer een lange zoektocht bezorgd

[ Voor 8% gewijzigd door Ruubster op 05-01-2016 23:17 ]

[Gomez12]

Ruubster schreef op dinsdag 05 januari 2016 @ 23:13:
[...]
Volgens mij klopt het niet wat je zegt, empty() geeft ook FALSE terug als de var niet bestaat. De var hoeft dus niet te bestaan, ook volgens de docs niet:

Dat schuif ik maar meer af op de rariteiten van php

Meeste andere talen geven gewoon een exceptie / error af als de var niet zou bestaan zodat je daar de uitzondering ermee uit zou kunnen filteren.

Ik vind het wel een vreemde functie, want 0 is dus leeg, 0.0 is leeg, maar 0.00 niet. Heeft me al een paar keer een lange zoektocht bezorgd

Dit specifieke geval is volkomen logisch en in bijna iedere taal afhankelijk van oa de lokale instellingen...

[Voutloos]

Ik blijf corrigeren, 3-maal is scheepsrecht.

Ruubster schreef op dinsdag 05 januari 2016 @ 23:13:
[...]

Volgens mij klopt het niet wat je zegt, empty() geeft ook FALSE terug als de var niet bestaat. De var hoeft dus niet te bestaan, ook volgens de docs niet

Daar staat 'A variable is considered empty if it does not exist...' ergo empty($void) === true.

Ik vind het wel een vreemde functie, want 0 is dus leeg, 0.0 is leeg, maar 0.00 niet. Heeft me al een paar keer een lange zoektocht bezorgd

0.00000000000 werkt ook zoals je verwacht: https://3v4l.org/qSPcI

In de link zie je ook dat de var_dump ook steeds float 0 is. Die lange zoektocht was wellicht met een float die toch net niet helemaal 0 was of iets dergelijks.
_{flauw: Elk van deze snippets is natuurlijk ook binnen 5 seconde getest. Zou zo maar minder werk zijn dan t tikken vd rest van een post.}

---

Terug naar PHP7 features: Eindelijk fatsoenlijke random_int() en random_bytes() functies is ook best wel fijn. \o/

[ Voor 37% gewijzigd door Voutloos op 05-01-2016 23:49 ]

[Ruubster]

Gomez12 schreef op dinsdag 05 januari 2016 @ 23:25:


[...]

Dit specifieke geval is volkomen logisch en in bijna iedere taal afhankelijk van oa de lokale instellingen...

Daar heb je inderdaad gelijk in, ik had niet gedacht aan de lokale instellingen.

Voutloos schreef op dinsdag 05 januari 2016 @ 23:36:

[...]
0.00000000000 werkt ook zoals je verwacht: https://3v4l.org/qSPcI

In de link zie je ook dat de var_dump ook steeds float 0 is. Die lange zoektocht was wellicht met een float die toch net niet helemaal 0 was of iets dergelijks.
_{flauw: Elk van deze snippets is natuurlijk ook binnen 5 seconde getest. Zou zo maar minder werk zijn dan t tikken vd rest van een post.}

---

Terug naar PHP7 features: Eindelijk fatsoenlijke random_int() en random_bytes() functies is ook best wel fijn. \o/

Waarschijnlijk was het bij mij toch geen float of iets raars of zo. Geen idee.

Binnenkort maar eens PHP7 testen op mijn server!

[ Voor 54% gewijzigd door Ruubster op 06-01-2016 10:44 ]

[Barryvdh]

Dat er nu geen errors meer gegooid worden, maar voor interne functies ook gewoon Exceptions worden gebruikt, is ook wel handig; http://php.net/manual/en/language.errors.php7.php

En natuurlijk de performance boost, soms vaak 2x zo snel http://www.zend.com/en/resources/php7_infographic

[Gomez12]

Barryvdh schreef op woensdag 06 januari 2016 @ 10:53:
Dat er nu geen errors meer gegooid worden, maar voor interne functies ook gewoon Exceptions worden gebruikt, is ook wel handig; http://php.net/manual/en/language.errors.php7.php

Ach, het blijft op zijn php's gaan. Ik wil niet echt gaan tellen hoevaak er op die pagina staat "most errors" oftewel niet "all errors"

En natuurlijk de performance boost, soms 2x zo snel http://www.zend.com/en/resources/php7_infographic

Soms tot 2x zo snel, dat zijn van die zinloze uitspraken. Wat is het gemiddelde, want als het soms 2x zo snel is maar in 95% van de gevallen 3x zo traag is dan wordt alsnog niemand er vrolijk van.

[Barryvdh]

Gomez12 schreef op woensdag 06 januari 2016 @ 12:27:
[...]

Ach, het blijft op zijn php's gaan. Ik wil niet echt gaan tellen hoevaak er op die pagina staat "most errors" oftewel niet "all errors"

Het gaat er ook om dat het vanaf nu de 'standaard' is en nieuwe functies dat gebruiken, en oude worden geconverteerd, indien mogelijk. Zie ook https://wiki.php.net/rfc/engine_exceptions_for_php7
Het blijkt niet 100% mogelijk te zijn, maar als het voor de meeste use-cases wel is, is dat iig een stuk beter.

The Zend Engine currently (master on 2014-09-30) contains the following number of fatal-y errors:

E_ERROR: 182 (note: not counting 636 occurrences in zend_vm_execute.h)
E_CORE_ERROR: 12
E_COMPILE_ERROR: 146
E_PARSE: 1
E_RECOVERABLE_ERROR: 17
The count was obtained using git grep “error[^(]*(E_ERROR_TYPE” Zend | wc -l and as such may not be totally accurate, but should be a good approximation.

The patch attached to the RFC currently (as of 2014-09-30) removes 75 E_ERRORs, 13 E_RECOVERABLE_ERRORs and the one E_PARSE error. While I hope to port more errors to exceptions before the patch is merged, the process is rather time consuming and I will not be able to convert all errors. (Note: The number of occurrences in the source code says rather little about what percentage of “actually thrown” errors this constitutes.)

Some errors are easy to change to exceptions, others are more complicated. Some are impossible, like the memory limit or execution time limit errors. The E_CORE_ERROR type can't be converted to use exceptions because it occurs during startup (at least if used correctly). Converting E_COMPILE_ERROR to exceptions would also require some significant changes to the compiler.

This means that there will always be some truly fatal errors and to a userland developer the distinction between what results in an exception and what in a fatal error may be non-obvious. I don't think that this is really a problem. Not being able to make everything an exception is no reason to avoid exceptions in the cases where they can be used.

Gomez12 schreef op woensdag 06 januari 2016 @ 12:27:

[...]

Soms tot 2x zo snel, dat zijn van die zinloze uitspraken. Wat is het gemiddelde, want als het soms 2x zo snel is maar in 95% van de gevallen 3x zo traag is dan wordt alsnog niemand er vrolijk van.

Oke, voor zover ik kan zien op internet is het grofweg in de meeste gevallen 100% winst (dus 2x zo snel), maar het hangt natuurlijk af van wat je script doet allemaal. De 100% winst komt vanuit de meeste benchmarks met frameworks en default settings.
Naast de infographic van vorige post, ook bijv; http://talks.php.net/oz15#/drupalbench
Over dat het langzamer is, heb ik niks gehoord nog (op een bug of edge-case na misschien)

Hier ook meer dingen over PHP 7: https://github.com/tpunt/PHP7-Reference

[Gomez12]

Barryvdh schreef op woensdag 06 januari 2016 @ 12:42:
[...]
Het gaat er ook om dat het vanaf nu de 'standaard' is en nieuwe functies dat gebruiken, en oude worden geconverteerd, indien mogelijk. Zie ook https://wiki.php.net/rfc/engine_exceptions_for_php7
Het blijkt niet 100% mogelijk te zijn, maar als het voor de meeste use-cases wel is, is dat iig een stuk beter.

Zoals ik al zeg, het gaat op zijn phps...
Er moet gereleased worden en dat er dan dingen niet compleet af zijn (maar slechts voor de meeste use-cases) tja, dat nemen ze dan maar voor lief.

Ik vind dat leuk voor intermediate releases, maar voor een major release zou ik toch zeggen fix het allemaal zodat vanaf de nieuwe major release er 1 aan te raden werkwijze is. Nu is er met versie 7 gewoon een verschil tussen de zo goed als 100% bruikbare werkwijze en de aan te raden werkwijze (exceptions).

[...]
Oke, voor zover ik kan zien op internet is het grofweg in de meeste gevallen 100% winst (dus 2x zo snel), maar het hangt natuurlijk af van wat je script doet allemaal. De 100% winst komt vanuit de meeste benchmarks met frameworks en default settings.
Naast de infographic van vorige post, ook bijv; http://talks.php.net/oz15#/drupalbench
Over dat het langzamer is, heb ik niks gehoord nog (op een bug of edge-case na misschien)

Infographics zijn altijd compleet nietszeggend als het over een programmeertaal en snelheid gaat. Wat er op internet etc staat is een gigantisch groffe indicatie.
Het enige wat er toe doet is is hoe je eigen applicatie zich verhoudt, de rest van de infographics is gebakken lucht.

Hier ook meer dingen over PHP 7: https://github.com/tpunt/PHP7-Reference

https://github.com/tpunt/...ivision-by-zero-semantics
Dus we hebben een DivisionByZeroError Exception, maar deze treedt niet op bij een division (want dan krijg je een float en een warning) maar wel bij een modulus.

Maar als ik die pagina zo lees, zijn ze eindelijk eens op de goede weg met puinruimen, alleen dat betekent concreet wel dat overgangen naar php7 extreem moeilijk gaan worden (en naar vervolgversies als ze doorgaan met puinruimen) want er zitten vrij veel breaking changes in die vrij tricky zijn

[Barryvdh]

Gomez12 schreef op woensdag 06 januari 2016 @ 14:39:
[...]

Zoals ik al zeg, het gaat op zijn phps...
Er moet gereleased worden en dat er dan dingen niet compleet af zijn (maar slechts voor de meeste use-cases) tja, dat nemen ze dan maar voor lief.

Ik vind dat leuk voor intermediate releases, maar voor een major release zou ik toch zeggen fix het allemaal zodat vanaf de nieuwe major release er 1 aan te raden werkwijze is. Nu is er met versie 7 gewoon een verschil tussen de zo goed als 100% bruikbare werkwijze en de aan te raden werkwijze (exceptions).

Maar gewoon errors gooien is niet '100% bruikbaar', tenzij je errors wil supressen met @. Voor zover het mogelijk is, worden er gewoon Exceptions gebruikt die je can catchen. Als het niet mogelijk was door te converteren, veranderd er niks dus tov eerst..

Gomez12 schreef op woensdag 06 januari 2016 @ 14:39:
Infographics zijn altijd compleet nietszeggend als het over een programmeertaal en snelheid gaat. Wat er op internet etc staat is een gigantisch groffe indicatie.
Het enige wat er toe doet is is hoe je eigen applicatie zich verhoudt, de rest van de infographics is gebakken lucht.

Klopt, maar je zal ergens mee moeten vergelijken. En een Wordpress/Drupal/Magento etc zijn nou eenmaal wel makkelijk op te zetten, en geven iig iets van een indicatie (aangezien veel websites dat gewoon ook draaien). Het wijst er iig allemaal op dat het een stuk sneller is allemaal

[ Voor 0% gewijzigd door Barryvdh op 06-01-2016 20:00 . Reden: Kan niet suppressen, gaat niet om warnings. ]

[Gomez12]

Barryvdh schreef op woensdag 06 januari 2016 @ 14:57:
[...]
Maar gewoon errors gooien is niet '100% bruikbaar', tenzij je errors wil supressen met @.

???
Gewoon errors laten lopen naar separate logging en je hoeft niets te supressen.

Voor zover het mogelijk is, worden er gewoon Exceptions gebruikt die je can catchen. Als het niet mogelijk was door te converteren, veranderd er niks dus tov eerst..

Zie vorige post, je introduceert een divisionbyzeroexception, maar je past hem niet toe bij een division by zero. Denk je echt dat het niet mogelijk was om die daar ook te introduceren?

[...]
Klopt, maar je zal ergens mee moeten vergelijken. En een Wordpress/Drupal/Magento etc zijn nou eenmaal wel makkelijk op te zetten, en geven iig iets van een indicatie (aangezien veel websites dat gewoon ook draaien). Het wijst er iig allemaal op dat het een stuk sneller is allemaal

Het nadeel vind ik juist weer dat die dingen vrij nietszeggend zijn (kennis van wel 1 1/2 tot 2 jaar geleden toen ik er nog iets in deed) omdat ik ze in de praktijk bijna nergens vanilla zag draaien, ze zaten allemaal volgepropt met plugins etc die voor ongeveer 95% de performance bepaalden en daarna zaten die plugins weer veelal vol met inefficiente query's etc waardoor de database ook nog eens een giga-impact had.

Wellicht dat mijn kennis achterhaald is en nu bijna iedereen vanilla wp/drupal/magento draait en het dus enigszins te vergelijken is, maar dat was niet mijn ervaring.

[Barryvdh]

Gomez12 schreef op woensdag 06 januari 2016 @ 18:07:
[...]

???
Gewoon errors laten lopen naar separate logging en je hoeft niets te supressen.

[...]

Zie vorige post, je introduceert een divisionbyzeroexception, maar je past hem niet toe bij een division by zero. Denk je echt dat het niet mogelijk was om die daar ook te introduceren?

My bad, errors supressen is niet relevant, want het gaat alleen om Fatal errors. Dat zal ook de reden zijn dat die division by zero niet veranderd. Het gedrag was al om een warning te geven met een resultaat. Om de BC breaks te beperken, zal dat niet gewijzigd zijn denk ik.

Maar een Recoverable Fatal Error kan je ook met een error_handler opvangen (en Exception gooien, zoals in de RFC als voorbeeld staat ook, al is dat zeker niet standaard), maar een normale Fatal Error stopt, zoals ook beschreven, dus het script en de error handler wordt niet aangeroepen. Je kan dus ook niet verder met je script, alleen hoogstens de shutdown handler uit laten voeren om iets te loggen.
En Exceptions hebben standaard de backtrace met meer informatie, 'finally' wordt uitgevoerd etc.

[Gomez12]

Barryvdh schreef op woensdag 06 januari 2016 @ 20:07:
[...]
Dat zal ook de reden zijn dat die division by zero niet veranderd. Het gedrag was al om een warning te geven met een resultaat. Om de BC breaks te beperken, zal dat niet gewijzigd zijn denk ik.

Waarmee je dus weer zo'n typische php-situatie creeert dat je een exception hebt die een bepaalde naam heeft die lijkt iets te maken te hebben met iets (divide by zero), maar daar eigenlijk totaal niets mee te maken heeft en ergens anders voor is.

Noem dat ding dan modulusbyzeroexception als wat jij stelt echt de doelstelling is, dan is het voor iedereen duidelijk waarbij die optreed en als die optreed waarnaar je moet gaan zoeken.

[Voutloos]

'Totaal niets mee te maken' is ook beetje overdreven, delen en modulo zijn niet helemaal losse begrippen.

Bovendien is division by zero daadwerkelijk al iets verbeterd: je krijgt nu een float(INF) terug, ipv false welke je al te makkelijk met 0 zou kunnen vergelijken. Het is inderdaad geen exception, misschien vanwege B/C, misschien omdat het niet helemaal makkelijk te fixen was.

Voor een echt strenge integer division, welke ook de exception gooit, en integer args en return var afdwingt heb je nu intdiv(). Als je toch zo zeker weet dat je strict met integers werkt kan je net zo goed dat expliciet in je code zetten.

Voor alle PHP5 code ooit geldt dat het een handig idee is om een error_handler te maken welke Exceptions gooit als je graag strict werkt. Dat kan je al bijna 10 jaar stom vinden, prima, dat is het ook, maar dan nog heb je dit al geregeld. In PHP7 gaat het gros meer native en dat is alleen maar mooi. Helaas nog niet alles, maar je kan het ook als een positieve stap zien.

En last but not least: Je hamert hier op een detail, waarbij je ook de goede aspecten (return value, modulo al verbeterd, expliciete intdiv() function) voor het gemak opzij schuift. Sure, soms zo het leuk zijn als het nog progressiever of doortastender zou gaan, maar bottomline is 7 wel gewoon een grote sprong vooruit.

De DivisionByZeroError is uberhaupt een van de kleinere, ondergeschikte wijzigingen imo. Er zitten zeker 10 veel grotere, meer ingrijpender wijzigingen in. Als je dan alleen maar op deze edge case (welke maar wat vaak uberhaupt niet voorkomt ivm constante deler, of inputvalidatie op een eerdere logische plek, en met warning die je altijd al niet moest negeren), ben je ook wel een beetje spijkers op laag water aan het zoeken.

[Icelus]

There Will Be Many Features Coming For PHP 7.1
PHP 7 was just released over one month ago but there is already much work going into PHP 7.1, the next major update to this widely-used web programming language.

PHP 7.0 is most notable for the huge performance improvements compared to PHP5 and some new language features. With PHP 7.1, there are more features coming for when it's released later this year.

For some weekend reading, I was poking around for a look at some PHP 7.1 features already committed as well as some other likely material.

The tentative news items for work already found in PHP Git includes:

• PHP 7.1 adds support for a void return type.
• SHA3 fixed mode algorithms were added.
• The bundled SQLite library is updated against 3.9.2 rather than 3.8.
• Various bug fixes and other minor improvements.

Other items being planned and/or talked about for PHP 7.1 include:

• PHP Cryptography Objects (PCO) for better encryption/decryption/signing.
• Short closures.
• Generic types and functions.
• HTTP/2 and server push support.

Other proposals for future releases of PHP (not necessarily PHP 7.1) can be found via the RFC Wiki area. Stay tuned for more coverage of PHP 7.1 as its release approaches later in the year.

Short closures
https://wiki.php.net/rfc/short_closures

PHP:

function ($x) {
    return $x * 2;
}

// would be equivalent to the new syntax:

$x ~> $x * 2

PHP:

usort($array, 
    function($a, $b) {
        return $a->val <=> $b->val; 
    }
);

// New syntax:

usort($array, ($a, $b) ~> $a->val <=> $b->val);

Generic types
https://wiki.php.net/rfc/generics

PHP:

class Entry<KeyType, ValueType>
{
    protected $key;
    protected $value;
 
    public function __construct(KeyType $key, ValueType $value)
    {
        $this->key   = $key;
        $this->value = $value;
    }
 
    public function getKey(): KeyType
    {
        return $this->key;
    }
 
    public function getValue(): ValueType
    {
        return $this->value;
    }
}

$entry = new Entry<int,string>(1, 'test');

[Gomez12]

Voutloos schreef op woensdag 06 januari 2016 @ 22:33:
En last but not least: Je hamert hier op een detail, waarbij je ook de goede aspecten (return value, modulo al verbeterd, expliciete intdiv() function) voor het gemak opzij schuift. Sure, soms zo het leuk zijn als het nog progressiever of doortastender zou gaan, maar bottomline is 7 wel gewoon een grote sprong vooruit.

Tja, daar verschil ik van mening over... Ik zie waarom ze het doen (ik vermoed dat als ze alle wijzigingen daadwerkelijk afmaken en dan pas releasen dat ze het net zo goed geen php meer kunnen noemen zover zal het afstaan van php5 en co)

Alleen dat maakt nog niet dat ik het een goed idee vind om half uitgedachte implementaties etc maar te releasen onder het motto : Het brengt nog meer inconsistentie zolang het half is, maar in de loop der tijd zal het consistenter worden...

[Voutloos]

Ik weet niet zeker of t 'meer inconsistent' is. Warnings en Exceptions leven inderdaad al te lang naast elkaar. Dat is inconsistent, maar t enige dat er nu (langzaam) gebeurt, is dat de ratio verbetert.

[HollowGamer]

Icelus schreef op dinsdag 12 januari 2016 @ 10:14:
[..]

Komt er nu een crypt class/functie(s) bij? Of bedoelen ze dat de onderliggende code beter wordt beveiligd?

Waarom zou ik die generic types willen gebruiken? Of beter gezegd waarvoor worden zs gebruikt?

[ Voor 77% gewijzigd door HollowGamer op 12-01-2016 20:47 ]

[Barryvdh]

HollowGamer schreef op dinsdag 12 januari 2016 @ 20:45:
[...]

Komt er nu een crypt class/functie(s) bij? Of bedoelen ze dat de onderliggende code beter wordt beveiligd?

Waarom zou ik die generic types willen gebruiken? Of beter gezegd waarvoor worden zs gebruikt?

In principe zouden de RFC's hier te vinden moeten zijn: https://wiki.php.net/rfc#request_for_comments
Maar zie daar zo snel niets over die PCO extensie.

[Icelus]

Praktijkvoorbeeld: How Badoo saved one million dollars switching to PHP7.

[Voutloos]

^ Leuke blogpost, met diverse links en verhalen over tests en procedures.

[HollowGamer]

Voutloos schreef op dinsdag 15 maart 2016 @ 13:50:
^ Leuke blogpost, met diverse links en verhalen over tests en procedures.

Ziet er inderdaad erg handig uit!

Ook hier niet de switch gemaakt naar HHVM; lees ook terug dat zij uiteindelijk gewacht hebben op PHP7.
Opzicht ben ik nog altijd positief naar een HHVM switch, maar er zijn dus nog een aantal negatieve punten/issues.

Met PHP7 zijn er leuke features bijgekomen, problemen opgelost en lijkt er eindelijk geluisterd te worden naar de developers (als ik zo de positieve berichten lees op het *net).

[Icelus]

Upcoming changes in PHP 7.1

Below are the key changes that will be introduced (or removed) in PHP 7.1. For a full list, and to see which changes are being discussed, check out the official PHP RFC.

• Catching multiple exception types
• Curl HTTP/2 server push support
• Support class constant visibility
• Void return types
• Generalize support of negative string offsets
• Allow specifying keys in list() and square bracket syntax for array destructuring
• Warn about invalid strings in arithmetic
• Deprecate and remove mcrypt()

[...]

[Ventieldopje]

- Support class constant visibility
- Void return types

YES! Nu nog method overloading en dan ben ik helemaal tevreden

[HollowGamer]

Icelus schreef op zondag 22 mei 2016 @ 10:37:
[...]

Mooi dat het nu ook mogelijk is meerdere Exceptions in één keer op te vangen.

Ben ik de enige die de nieuwe syntax minder leesbaar vind?
Je hoeft nu als het ware geen (simpel voorbeeld)

code:

functie optellen() { return 1 + 1; }

te schrijven, maar die extra regels maken het in zijn geheel wat duidelijker.

Verder zijn er ook nieuwe tags bij classes, etc. ook deze zijn in mijn ogen wat verwarrend.. maar misschien moet ik de drafts nog maar eens nalezen.

[azerty]

HollowGamer schreef op maandag 23 mei 2016 @ 13:14:
[...]

Mooi dat het nu ook mogelijk is meerdere Exceptions in één keer op te vangen.

Ben ik de enige die de nieuwe syntax minder leesbaar vind?
Je hoeft nu als het ware geen (simpel voorbeeld)

code:

functie optellen() { return 1 + 1; }

te schrijven, maar die extra regels maken het in zijn geheel wat duidelijker.

Verder zijn er ook nieuwe tags bij classes, etc. ook deze zijn in mijn ogen wat verwarrend.. maar misschien moet ik de drafts nog maar eens nalezen.

Over welke nieuwe syntax heb je het?

Ik vind de verbeteringen niet slecht, PHP gaat mooi vooruit op die manier

[HollowGamer]

azerty schreef op maandag 23 mei 2016 @ 13:21:
[...]


Over welke nieuwe syntax heb je het?

Ik vind de verbeteringen niet slecht, PHP gaat mooi vooruit op die manier

Zie o.a. deze: https://wiki.php.net/rfc/short_closures

[Icelus]

Ventieldopje schreef op zondag 22 mei 2016 @ 16:25:
[...]


YES! Nu nog method overloading en dan ben ik helemaal tevreden

Is dat überhaupt (makkelijk) in een taal als PHP mogelijk?

PHP:

function fun(int $a) {
  echo ( $a * 2 );
}

function fun(string $a) {
   echo $a;
}

fun( 123 ); // OK
fun("¡Hola, mundo!"); // OK
fun("123"); // OK?

Doordat PHP automatisch typeconversie uitvoert zal niet altijd de verwachtte functie gekozen worden.

Edit: aantal parameters is wel te onderscheiden per functie.

[ Voor 5% gewijzigd door Icelus op 23-05-2016 13:49 ]

[ThomasG]

Icelus schreef op maandag 23 mei 2016 @ 13:47:
[...]
Is dat überhaupt (makkelijk) in een taal als PHP mogelijk?

PHP:

function fun(int $a) {
  echo ( $a * 2 );
}

function fun(string $a) {
   echo $a;
}

fun( 123 ); // OK
fun("¡Hola, mundo!"); // OK
fun("123"); // OK?

Doordat PHP automatisch typeconversie uitvoert zal niet altijd de verwachtte functie gekozen worden.

Edit: aantal parameters is wel te onderscheiden per functie.

PHP doet in ieder geval in PHP7 niet meer aan automatische typeconversie. Een gettype("123"); geeft namelijk string, enkel bij een cast wordt het een integer. Overloading zou dus gewoon mogelijk moeten zijn.

[azerty]

HollowGamer schreef op maandag 23 mei 2016 @ 13:41:
[...]

Zie o.a. deze: https://wiki.php.net/rfc/short_closures

Die is er ondertussen al niet meer (withdrawn). Deze (https://wiki.php.net/rfc/arrow_functions) is wel nog actueel, maar dat is nog maar een discussie op dit moment...

Mij lijkt het geen probleem, zal sowieso nog een tijdje duren tegen dat dit er in komt denk ik

[Voutloos]

ThomasG schreef op maandag 23 mei 2016 @ 13:53:
[...]
PHP doet in ieder geval in PHP7 niet meer aan automatische typeconversie. Een gettype("123"); geeft namelijk string, enkel bij een cast wordt het een integer. Overloading zou dus gewoon mogelijk moeten zijn.

Zo heeft de 'typeconversie' nooit gewerkt hoor. https://3v4l.org/Q6ZSL

Er zijn wel wat verbeteringen, zoals ook in 7.1 met de 'non well formed numeric string'-notice (zie bovenstaande blog https://dotdev.co/upcomin...php-7-1-76ebea53b820#07d1 ).
En er zijn ook wel eerdere verbeteringen op dit vlak, maar met triviaal foute voorbeelden wordt het niet duidelijker.

[Icelus]

ThomasG schreef op maandag 23 mei 2016 @ 13:53:
[...]
PHP doet in ieder geval in PHP7 niet meer aan automatische typeconversie. Een gettype("123"); geeft namelijk string, enkel bij een cast wordt het een integer. Overloading zou dus gewoon mogelijk moeten zijn.

Ik zat meer in de richting te denken dat er een string met een getal wordt doorgegeven voor gebruik in een berekening. PHP zal dit automatisch naar een int/float converteren.

[Icelus]

Voor wie nog geïnteresseerd is in de broncode van PHP en welke zaken gewijzigd zijn voor PHP 7:

• https://nikic.github.io/2...table-implementation.html
• https://nikic.github.io/2...tion-in-PHP-7-part-1.html
• https://nikic.github.io/2...tion-in-PHP-7-part-2.html
• PHP 7 – What changed internally? (PHP Barcelona 2015)

[ Voor 18% gewijzigd door Icelus op 26-05-2016 10:49 ]

[telefoontoestel]

HollowGamer schreef op dinsdag 05 januari 2016 @ 13:29:
Deze nieuwe feature vind ik wat vreemd:

PHP:

$v = $x ?? $z;

Dit wordt gedaan d.m.v. een isset, terwijl ik een empty() logischer zou vinden. Helaas kun je dit niet doen:

PHP:

$v = !empty($x) ?? $z;

Dan krijg je volgensmij empty op een isset?
Waarom empty? Dat is gezet is, wil nog niet zeggen dat het 'gevuld' is. Als voorbeeld op PHP.net wordt een $_GET gebruikt, en die wil je juist (in de meeste gevallen) niet leeg hebben.

Beetje late reactie, maar de empty variant bestaat al een tijd en dat is de emtpy-operator ?:.

PHP:

$v = $a ?: $b;

Het is dus erg handig dat nu ook de isset variant erbij is gekomen want nu kun je ook combineren:

PHP:

$v = $a ?? ($b ?? ($c ?: 0));

[edit]
Never mind Zie dat de operator halverwege het topic al eens is benoemd.

[ Voor 4% gewijzigd door telefoontoestel op 26-05-2016 20:03 ]

[Icelus]

PHP 7.1.0 Alpha 1 Released
The PHP development team announces the immediate availability of PHP 7.1.0 Alpha 1. This release marks the beginning of the first minor release in the PHP 7.x series. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system.

THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!

PHP 7.1.0 Alpha 1 comes with features such as (incomplete list):

• Nullable Types
• Square bracket syntax for array destructuring assignment
• Allow specifying keys in list()
• Generalize support of negative string offsets
• Void Return Type
• Class constant visibility modifiers
• Multi catch

[Icelus]

PHP 7.1.0 Released
The PHP development team announces the immediate availability of PHP 7.1.0. This release is the first point release in the 7.x series.

PHP 7.1.0 comes with numerous improvements and new features such as

• Nullable types
• Void return type
• Iterable pseudo-type
• Class constant visiblity modifiers
• Square bracket syntax for list() and the ability to specify keys in list()
• Catching multiple exceptions types
• Many more features and changes…

[HollowGamer]

Icelus schreef op vrijdag 2 december 2016 @ 09:10:
PHP 7.1.0 Released
The PHP development team announces the immediate availability of PHP 7.1.0. This release is the first point release in the 7.x series.

PHP 7.1.0 comes with numerous improvements and new features such as

• ..
• Catching multiple exceptions types

Voor multiple-exceptions stond het volgende:

PHP:

try
{
    // trigger error here
}

catch(CustomException1 | CustomException2 $e)
{
    // $e->getMessage();
}

Zou het niet moeten zijn?

PHP:

catch(CustomException1 $e | CustomException2 $e)

Of om nog meer te 'zeiken' :

PHP:

catch(CustomException1 $e || CustomException2 $e)

[ Voor 6% gewijzigd door HollowGamer op 02-12-2016 14:56 ]

[xehbit]

HollowGamer schreef op vrijdag 2 december 2016 @ 14:53:
[...]

Voor multiple-exceptions stond het volgende:

PHP:

try
{
    // trigger error here
}

catch(CustomException1 | CustomException2 $e)
{
    // $e->getMessage();
}

Zou het niet moeten zijn?

PHP:

catch(CustomException1 $e | CustomException2 $e)

Of om nog meer te 'zeiken' :

PHP:

catch(CustomException1 $e || CustomException2 $e)

Nope, volgens de release notes niet (zie: http://php.net/manual/en/...-catch-exception-handling)

[frickY]

Dan zou het niet erg duidelijk zijn in welke variabele je de exception beschikbaar hebt.

Veel irritanter vind ik het dat ze hiervoor de bitwise OR operator hebben herbruikt. Gebruik dan een komma, zoals ook met het implementen van meerdere interfaces.
Wat mij betreft maken ze een zooitje van de syntax.

Het kunnen assignen van een void function aan een variable heb ik ook geen enkel begrip voor.

PHP:

function someVoidFunction(): void
{
  //
}
$a = someVoidFunction();

geeft geen E_COMPILE_ERROR. maar $a = NULL

[ Voor 32% gewijzigd door frickY op 02-12-2016 15:08 ]

[HollowGamer]

xehbit schreef op vrijdag 2 december 2016 @ 15:00:
[...]


Nope, volgens de release notes niet (zie: http://php.net/manual/en/...-catch-exception-handling)

Dat is juist het punt dat ik wil aanduiden.
Het is inderdaad zo beschreven, maar waarom niet gewoon || of OR.

frickY schreef op vrijdag 2 december 2016 @ 15:04:
Dan zou het niet erg duidelijk zijn in welke variabele je de exception beschikbaar hebt.

Veel irritanter vind ik het dat ze hiervoor de bitwise OR operator hebben herbruikt. Gebruik dan een komma, zoals ook met het implementen van interfaces.

Wat mij betreft maken ze een zooitje van de syntax.

Dit zou toch ook kunnen:

PHP:

try
{
    // trigger error here
}

catch(WarningException $a || SuccessException $b)
{
    // $a->getMessage(): Only three products left in stock
    // $b->getMessage(): Product successfully added to basket
}

Twee verschillende foutmeldingen, niet helemaal goed, maar om maar een idee te geven.

[Barryvdh]

HollowGamer schreef op vrijdag 2 december 2016 @ 15:12:
[...]

Dat is juist het punt dat ik wil aanduiden.
Het is inderdaad zo beschreven, maar waarom niet gewoon || of OR.

[...]

Dit zou toch ook kunnen:

PHP:

try
{
    // trigger error here
}

catch(WarningException $a || SuccessException $b)
{
    // $a->getMessage(): Only three products left in stock
    // $b->getMessage(): Product successfully added to basket
}

Twee verschillende foutmeldingen, niet helemaal goed, maar om maar een idee te geven.

Als je ze verschillend wil behandelen is de oude manier toch al goed? Dit gaat erom dat je 2 verschillende Exceptions op dezelfde manier wil verwerken.

[xehbit]

HollowGamer schreef op vrijdag 2 december 2016 @ 15:12:
[...]

Dat is juist het punt dat ik wil aanduiden.
Het is inderdaad zo beschreven, maar waarom niet gewoon || of OR.

[...]

Dit zou toch ook kunnen:

PHP:

try
{
    // trigger error here
}

catch(WarningException $a || SuccessException $b)
{
    // $a->getMessage(): Only three products left in stock
    // $b->getMessage(): Product successfully added to basket
}

Twee verschillende foutmeldingen, niet helemaal goed, maar om maar een idee te geven.

Wanneer je verschillende errors wilt afvangen zou ik gewoon een extra catch blok toevoegen om dit af te handelen.

PHP:

try
{
    // trigger error here
}

catch(WarningException $a)
{
    // $a->getMessage(): Only three products left in stock
}

catch(SuccessException $b)
{
    // $b->getMessage(): Product successfully added to basket
}

Dit is meer om meerdere exceptions af te vangen waar je hetzelfde mee wilt doen.

[Icelus]

frickY schreef op vrijdag 2 december 2016 @ 15:04:
Het kunnen assignen van een void function aan een variable heb ik ook geen enkel begrip voor.

PHP:

function someVoidFunction(): void
{
  //
}
$a = someVoidFunction();

geeft geen E_COMPILE_ERROR. maar $a = NULL

Kan momenteel niet testen op PHP 7.1 maar vermoed dat het op te lossen is met ‘declare(strict_types=1);’.

PHP:

function gimmeInt():int {
    return 123;
}

function gimmeString():string {
    return '123';
}

var_export( gimmeInt() );     echo "\n";
var_export( gimmeString() );  echo "\n";

123
'123'

PHP:

function gimmeInt():int {
    return '123';
}

function gimmeString():string {
    return 123;
}

var_export( gimmeInt() );     echo "\n";
var_export( gimmeString() );  echo "\n";

123
'123'

PHP:

declare( strict_types=1 );

function gimmeInt():int {
    return '123';
}

function gimmeString():string {
    return 123;
}

var_export( gimmeInt() );     echo "\n";
var_export( gimmeString() );  echo "\n";

PHP Fatal error:  Uncaught TypeError: Return value of gimmeInt() must be of the type integer, string returned in types.php:5
Stack trace:
#0 types.php(12): gimmeInt()
#1 {main}
  thrown in types.php on line 5

[ Voor 3% gewijzigd door Icelus op 03-12-2016 13:18 ]

[Gomez12]

frickY schreef op vrijdag 2 december 2016 @ 15:04:
Veel irritanter vind ik het dat ze hiervoor de bitwise OR operator hebben herbruikt. Gebruik dan een komma, zoals ook met het implementen van meerdere interfaces.
Wat mij betreft maken ze een zooitje van de syntax.

"Maken" Is het ooit geen zooitje geweest dan?
Ik dacht juist dat php7 een grote opschoonslag zou moeten zijn...

[XWB]

Icelus schreef op zaterdag 3 december 2016 @ 13:17:
[...]

Kan momenteel niet testen op PHP 7.1 maar vermoed dat het op te lossen is met ‘declare(strict_types=1);’.

Zonet getest met PHP 7.1 maar dat lost het niet op, je krijgt nog steeds NULL terug.

Dus maar even de RFC erbij gepakt, het enige wat void doet is:

Some people have asked about this, since return; and return null; are technically equivalent in PHP; when a return value isn't specified, PHP will produce null for you. However, choosing one over the other suggests intent.

https://wiki.php.net/rfc/void_return_type

[Ventieldopje]

XWB schreef op woensdag 7 december 2016 @ 17:00:
[...]


Zonet getest met PHP 7.1 maar dat lost het niet op, je krijgt nog steeds NULL terug.

Dus maar even de RFC erbij gepakt, het enige wat void doet is:


[...]


https://wiki.php.net/rfc/void_return_type

Dan klopt het dus ook wel dat je null terug krijgt, lijkt me ook veel praktischer.

[Icelus]

XWB schreef op woensdag 7 december 2016 @ 17:00:
[...]


Zonet getest met PHP 7.1 maar dat lost het niet op, je krijgt nog steeds NULL terug.

Dus maar even de RFC erbij gepakt, het enige wat void doet is:


[...]


https://wiki.php.net/rfc/void_return_type

Ik zie het: als je geen waarde teruggeeft óf "return;" gebruikt compileert de code maar krijg je als waarde NULL terug. Je zou kunnen stellen dat dit dan al een fout is van de programmeur om een waarder terug te verwachten

HHVM werkt wat dat betreft beter:

code:

function gimmeVoid():void {
    return;
}

$i = 123;
$i = gimmeVoid();
var_export( $i );

Dit levert de volgende fout op:

code:

Catchable fatal error:
Value returned from function gimmeVoid() must be of type void, null given in test.php on line 3

[Ventieldopje]

Icelus schreef op woensdag 7 december 2016 @ 17:50:
[...]

Ik zie het: als je geen waarde teruggeeft óf "return;" gebruikt compileert de code maar krijg je als waarde NULL terug. Je zou kunnen stellen dat dit dan al een fout is van de programmeur om een waarder terug te verwachten

HHVM werkt wat dat betreft beter:

code:

function gimmeVoid():void {
    return;
}

$i = 123;
$i = gimmeVoid();
var_export( $i );

Dit levert de volgende fout op:

code:

Catchable fatal error:
Value returned from function gimmeVoid() must be of type void, null given in test.php on line 3

Wauw, hoe ga je dan vroegtijdig "returnen"?

[frickY]

http://stackoverflow.com/a/30198434/2454720

Author of the return types RFC here. In PHP 7.0 there will not be void return types since the RFC didn't add it and neither did any other RFC targeting PHP 7.0.
Personally, I don't think we need void; we already have null

In PHP a function which doesn't return anything will implicitly return null. This means that you cannot ever actually return nothing*. Going the null route means that there are no backwards compatibility breaks

[ Voor 218% gewijzigd door frickY op 08-12-2016 10:57 ]

[XWB]

Ik had liever de HHVM implementatie gezien, nu het voelt alsof het void return type voor spek en bonen toegevoegd is.

[Barryvdh]

XWB schreef op donderdag 8 december 2016 @ 11:03:
Ik had liever de HHVM implementatie gezien, nu het voelt alsof het void return type voor spek en bonen toegevoegd is.

Vanuit de RFC (https://wiki.php.net/rfc/void_return_type)

Support for a new void return type is added. It requires that a function not return any value:

PHP:

function should_return_nothing(): void {
    return 1; // Fatal error: A void function must not return a value
}

Unlike other return types which are enforced when a function is called, this type is checked at compile-time, which means that an error is produced without the function needing to be called.

Terwijl de null return dus niet compile time is, maar tijdens het uitvoeren van de functie (en kan afhankelijk zijn van variabelen etc). Dus wel degelijk een verschil toch?

En over het gebruiken van het resultaat van je void functions in je code:

Use of void functions in expressions

In some other languages, such as C, a void function can't be used in an expression, only as a statement. Since this RFC adds a way to specify a void function to PHP's syntax, it might be expected the same restriction would now apply in PHP. However, this wouldn't match precedent. PHP has had 'void functions' of a kind since its inception, in the form of built-in functions, which are documented as “void” in the manual. Such functions can be used in expressions, unlike in C.

We could change PHP's rules on void functions and disallow their use in expressions, but this would create a backwards-compatibility issue: it's not inconceivable that existing PHP code relies on being able to call built-in void functions in expressions, and plenty of code assumes that you can take the return value of an arbitrary PHP function (a callback, perhaps).

Moreover, IDEs and other tools can warn the user when the return value of a void function is being used. It isn't strictly necessary for the language itself to cover this.

Dus gedaan om in lijn te blijven met de rest van PHP en BC makkelijker te maken.

[Olaf van der Spek]

Heeft PHP nu al startswith and endswith functies?

[Barryvdh]

Olaf van der Spek schreef op vrijdag 9 december 2016 @ 16:36:
Heeft PHP nu al startswith and endswith functies?

Want die zijn zo lastig om zelf te schrijven?

[Ventieldopje]

Olaf van der Spek schreef op vrijdag 9 december 2016 @ 16:36:
Heeft PHP nu al startswith and endswith functies?

PHP:

function startswith($haystack, $needle) {
    return substr($haystack, 0, 1) === $needle;
}
function endswith($haystack, $needle) {
    return substr($haystack, -1, 1) === $needle;
}

Of wat stiekem ook gewoon werkt:

PHP:

function startswith($haystack, $needle) {
    return $haystack[0] === $needle;
}
function endswith($haystack, $needle) {
    return $haystack[strlen($haystack) - 1] === $needle;
}

[ Voor 23% gewijzigd door Ventieldopje op 10-12-2016 12:58 ]

[Olaf van der Spek]

Barryvdh schreef op vrijdag 9 december 2016 @ 21:55:
[...]

Want die zijn zo lastig om zelf te schrijven?

Ja, de poster onder je lukt het al niet.
En sinds wanneer is dat een reden om een functie niet op te nemen in de standaard library?

[ Voor 17% gewijzigd door Olaf van der Spek op 09-12-2016 23:17 ]

[Voutloos]

https://3v4l.org/eq1cK
In PHP 7.1 is '$haystack{-1} == $needle' dusdanig kort en triviaal dat ik er geen endsWithChar() voor ga schrijven.

En op deze manier kan ik alsnog een 7.1 feature noemen, is je geklets over een string functie toch nog ontopic.

Olaf van der Spek schreef op vrijdag 9 december 2016 @ 23:16:
En sinds wanneer is dat een reden om een functie niet op te nemen in de standaard library?

Dat blijft arbitrair, maar je hebt nu alsnog dus nieuwe syntax. Dit soort convenience methods kan je nu meer en meer in frameworks vinden en dat is imo prima; laat PHP core maar dingen toevoegen die je niet triviaal zelf aan eigen code of framework toe voegt.

offtopic:
En het is ook niet snel goed, er werd vroeger maar wat vaak gezeurd op de hoeveelheid string en array functions (los van de inconsistencies).

[ Voor 3% gewijzigd door Voutloos op 09-12-2016 23:31 ]

[Olaf van der Spek]

Voutloos schreef op vrijdag 9 december 2016 @ 23:30:
https://3v4l.org/eq1cK
In PHP 7.1 is '$haystack{-1} == $needle' dusdanig kort en triviaal dat ik er geen endsWithChar() voor ga schrijven.

Het gaat niet om chars maar om strings.. de lengte van de string wil je natuurlijk niet hard-coden en ook het kopiëren van de string wil je eigenlijk niet.

[Voutloos]

offtopic:
Ik ging uit van de poging van Ventieldopje, welke op een needle karakter lijkt te richten maar grappig genoeg ook meerdere bugs heeft. (reserved keyword in function name typo en [] ipv {})
Anyway, het doorzagen over een string functie lijkt een beetje bewust offtopic of trollerig. Open gerust een topic als je hulp nodig hebt dan kunnen we het hier over PHP 7 en 7.1 hebben.

[Ventieldopje]

Olaf van der Spek schreef op vrijdag 9 december 2016 @ 23:16:
[...]

Ja, de poster onder je lukt het al niet.
En sinds wanneer is dat een reden om een functie niet op te nemen in de standaard library?

Voutloos schreef op vrijdag 9 december 2016 @ 23:51:

offtopic:
Ik ging uit van de poging van Ventieldopje, welke op een needle karakter lijkt te richten maar grappig genoeg ook meerdere bugs heeft. (reserved keyword in function name typo en [] ipv {})
Anyway, het doorzagen over een string functie lijkt een beetje bewust offtopic of trollerig. Open gerust een topic als je hulp nodig hebt dan kunnen we het hier over PHP 7 en 7.1 hebben.

Typo? [ ] en { } werken beiden omdat een string ook gewoon een char array is. En welke reserved keywords meen jij te zien

Het is geen abracadabra. Pak in plaats van de length 1 gewoon de length van de needle en je kunt kijken of één string eindigt met de ander, of begint.

[ Voor 13% gewijzigd door Ventieldopje op 10-12-2016 00:41 ]

[Voutloos]

offtopic:
excuus, alleen de typo in functie naam. Ik gooide je code snel in 3v4l en dan ontdek je direct hoe toevallig je endswitch typo uitpakt. Maar goed, t topic wordt verneukt door hier op door te gaan, triviale funtie is triviaal. En offtopic

[Ventieldopje]

Voutloos schreef op zaterdag 10 december 2016 @ 07:58:

offtopic:
excuus, alleen de typo in functie naam. Ik gooide je code snel in 3v4l en dan ontdek je direct hoe toevallig je endswitch typo uitpakt. Maar goed, t topic wordt verneukt door hier op door te gaan, triviale funtie is triviaal. En offtopic

Smoesjes

/me deed even stiekem een ninja edit

Zie ook: https://3v4l.org/GISut#output

[ Voor 5% gewijzigd door Ventieldopje op 10-12-2016 13:59 ]

[Barryvdh]

Olaf van der Spek schreef op vrijdag 9 december 2016 @ 23:16:
[...]

Ja, de poster onder je lukt het al niet.
En sinds wanneer is dat een reden om een functie niet op te nemen in de standaard library?

Ik bedoelde inderdaad dat het geen noodzaak is om functies die prima in userland kunnen worden geïmplementeerd, toe te voegen aan de core. Gewoon een composer library gebruiken als het nodig is

[Icelus]

SlideShare: PHP 7.1 : elegance of our legacy.

[ Voor 5% gewijzigd door Icelus op 12-12-2016 10:23 ]

[Ventieldopje]

Icelus schreef op maandag 12 december 2016 @ 10:23:
SlideShare: PHP 7.1 : elegance of our legacy.

Ein-de-lijk ... een exception als een argument mist. Met een warning waren praktisch alle argumenten optioneel

Nou hopen dat we snel over kunnen op PHP 7(.1) en dat we niet die eeuwige python taferelen krijgen met hun oorlog tussen versie 2 en 3.

[Barryvdh]

Ventieldopje schreef op maandag 12 december 2016 @ 11:08:
[...]


Ein-de-lijk ... een exception als een argument mist. Met een warning waren praktisch alle argumenten optioneel

Nou hopen dat we snel over kunnen op PHP 7(.1) en dat we niet die eeuwige python taferelen krijgen met hun oorlog tussen versie 2 en 3.

Je kan nu al over op PHP7.1 als je graag wil

Wij draaien iig al enkele sites (Magento 1, Drupal 7, Laravel) en die draaien zonder problemen op PHP7 Ik verwacht ook geen problemen met 7.1

[ Voor 14% gewijzigd door Barryvdh op 12-12-2016 15:02 ]

[Ventieldopje]

Barryvdh schreef op maandag 12 december 2016 @ 14:48:
[...]

Je kan nu al over op PHP7.1 als je graag wil

Wij draaien iig al enkele sites (Magento 1, Drupal 7, Laravel) en die draaien zonder problemen op PHP7 Ik verwacht ook geen problemen met 7.1

Het draaien van (eigen) applicaties is geen probleem maar zolang een groot deel van de webhosts niet over is op PHP 7 / 7.1 dan heb je er als ontwikkelaar nog weinig aan.

Backwards compatible code schrijven terwijl je wel gebruik maakt van de nieuwe functies is niet te doen omdat er structureel ook aanpassingen in zitten. Dan zou je twee branches bij moeten houden, mij niet gezien

Helaas zie ik dat veel hosts nog steeds PHP 5.5 (EOL) of soms zelfs ouder draaien. Dus hopelijk durven ze het wél aan om de stap naar 7 te zetten als ze al niet de moeite durfden te nemen voor 5.6.

[Barryvdh]

Ventieldopje schreef op maandag 12 december 2016 @ 16:18:
[...]


Het draaien van (eigen) applicaties is geen probleem maar zolang een groot deel van de webhosts niet over is op PHP 7 / 7.1 dan heb je er als ontwikkelaar nog weinig aan.

Backwards compatible code schrijven terwijl je wel gebruik maakt van de nieuwe functies is niet te doen omdat er structureel ook aanpassingen in zitten. Dan zou je twee branches bij moeten houden, mij niet gezien

Helaas zie ik dat veel hosts nog steeds PHP 5.5 (EOL) of soms zelfs ouder draaien. Dus hopelijk durven ze het wél aan om de stap naar 7 te zetten als ze al niet de moeite durfden te nemen voor 5.6.

Mwoah, PHP5.6 heeft nog ruim 2 jaar security support, dus verwacht dat veel hosts voorlopig standaard daar op blijven. https://secure.php.net/supported-versions.php
Upgraden kan ook niet zomaar, als er nog applicaties met mysql_* op staan..

Dat gezegd hebbende, als ontwikkelaar mag je hopelijk toch zelf een hoster regelen/uitkiezen, of tenminste eisen stellen? Iig voor serieuze applicaties, maar ook een Digital Ocean server met php7.1 heb je al voor 5 of 10 euro.

Overigens net een paar Drupal sites verhuisd naar PHP7.1, daar waren ook maar een paar kleine aanpassingen voor nodig

[Icelus]

Kwam deze site tegen waarop de RFCs worden verzameld:
https://why-cant-we-have-nice-things.mwl.be/requests

Geeft een beeld wat er de komende versies kan worden verwacht.