
New Features in PHP 5.6 - gulbrandr
http://www.sitepoint.com/new-features-php-5-6/
======
asnyder
I really like the ...$param syntax. When we first created NOLOH
([http://www.noloh.com](http://www.noloh.com)) back in 2005 we decided on
$dotdotdot as a syntactic salt, but this is obviously much nicer. Also, by ref
... is really really nice. Very few cases where it's necessary, but having
that is a pretty big deal.

Since PHP 5.3, PHP has gotten some really nice features, they've definitely
been doing a pretty good job over the past few years.

------
agumonkey
Sure PHP had a lot of catch-up to do, but they're really on a fast pace these
days.

~~~
mildtrepidation
This is true. However, in my opinion, moving quickly is less important than
changing effectively. Effective change can happen quickly or slowly, depending
on the change intended and the effort required, but it's a different metric
than simply moving in some direction while retaining the previous state.

PHP is painful to work with for a lot of reasons. It's also very easy to work
with for a lot of reasons, but in my opinion, a lot of those -- despite being
considered by some to be strengths of the language -- are used, and in many
cases intended, to be shortcuts to functionality a more robust language would
embrace explicitly.

PHP suffers from many, many failures of design. It suffers further, and worse,
from an ongoing and intentional failure to address almost all of these
failures. It's Frankenstein's language. If it were sentient, it would rebel
and run off into some cold and inhospitable place.

A fast pace is velocity. They have that. What they don't have is a good
direction, and without a good direction, a long vector is at best a roll of
the dice.

~~~
Mikushi
Not sure what you are into but PHP is anything but painful to work with. It's
the easiest to get started, cheapest to run, and frankly when you actually use
it for what it is intended, output web pages, I fail to find better.

At the end of the day, if you keep it simple you can go far without ever
needing to do much maintenance and scaling. Most failure to scale I've seen
come from bloated code base and code written by people who are not PHP
developers.

------
foldor
I'm liking the variadic functions syntax. It's definitely better than
requiring all extra parameters to be sent as arrays. Even if that's how they
end up in the function.

~~~
apinstein
The current implementation doesn't require extra params as arrays... you can
pass as many (or as few) parameters to any PHP function regardless of defined
function signature; the declared parameters will be auto-populated.
Additionally, you can call func_get_args() inside of any function and get an
array with all params, meaning it's a trivial array_slice (and/or list) away
from extracting all vargs.

That said, the new ...$params is 100% better.

------
coldtea
The arguments in the linked email of some _Ilia Alshanetsky_ regarding the
shorthand array syntax are incredibly dense...

------
dhoulb
Would REEEEEEALLY like to see readonly properties in classes.

They had a proposal a while ago to add getter and setter function support,
which would be cool and would've allowed it (with some function overhead), but
is probably a bit OTT for PHP.

readonly properties would allow you to make truly solid classes. You'd be able
to lock them down from outside interference.

Methods could trust that property values hadn't been tampered with from
outside, while still providing a way for outside code to read those values
extremely quickly, without function overhead.

I think it's an awesome idea, especially since the getter/setter proposal
failed. It's very PHPy, and it strikes a nice middle ground between fully
public properties and private ones.

External code really shouldn't be able to mess with my class's internal
properties anyway, it violates separation of concerns.

~~~
krapp
I agree with you. This is the closest i've been able to get...

    
    
       class whatever{
         
         private $Properties=array();
    
         function __set($key,$val){
            try{
             if(!isset($this->Properties[$key])){
                $this->Properties[$key]=$val;
             }
            }catch(Exception $e){
            //...
            }
          }
    
          function __get($key){
           try{
            if(isset($this->Properties[$key])){
              return $this->Properties[$key];
            }
           }catch(Exception $e){
           //...
           }
         }
        }

~~~
datphp
Your code doesn't work...

The catch will never be called, and you should never use isset() because it
will return false if the value exists but is null.

    
    
        whatever->param = null;
        whatever->param = 123;
    

Both lines will execute here.

    
    
        function __set($k, $v){
            if (array_key_exists($k, $this->Properties)){
                throw new ReadOnlyException();
            }else{
                $this->Properties[$k] = $v;
            }
        }

~~~
krapp
Yes, thank you. I noticed the problem after it was too late to edit. Slightly
embarrassing.

------
leeoniya
i would love to see them make an explicit BC break and fix everything listed
at [http://phpsadness.com/](http://phpsadness.com/)

~~~
wvenable
If you break BC you might as well just another language, because that's what
it will be.

The correct approach is slow and steady improvements. I suspect standard
library improvements will come not by renaming existing functions but by
adding new API.

~~~
BugBrother
The Perl way is to declare minimum language version to execute a code file.
E.g. _use v5.12;_

Then you can do extensions [even _changing_ central functionality] in a sane
way, with backward compatibility. (A language implementation need to implement
deprecated features for older versions, of course.)

I agree with your point re APIs.

~~~
oafitupa
That's what we do with Composer, we set the minimum PHP version.

~~~
krapp
I've done and seen it done in wordpress plugins, sometimes.

------
poobrains
Any word on when all functions will be UTF-8 safe?

~~~
jcampbell1
Other than "substring", how often do you really run into this problem? I have
never had a problem with PHP and UTF-8.

Oh, good luck trying to match all unicode punctuation with Python/Javascript.
With php it is as simple as preg_match('/\pP/u'

I deal with a lot of UTF-8 issues, and while php is super ugly, there are
pretty good solutions in cases where it requires ugly hacks in other
languages.

~~~
Joeri
Sorry, but PHP's string handling is abysmal.

\- strlen can't be used for length checks if you care about length in
characters, a problem compounded when you use a real database where field
lengths are defined in characters instead of bytes

\- the only way to iterate char by char instead of byte per byte is to use
mb_substr, as there is no trick to make $str[$i] do anything but return bytes.

\- the string and array API's have inverse ordering of their parameters, which
means that after a decade of writing PHP I still can't remember which is which
without looking it up

\- Typing mb_ in front of everything is ugly enough, but it also makes
autocompletion tricky, especially since the strings don't have methods. (e.g.
$str->pos())

\- Speaking of which, since the strings don't have methods, they stick out
like a sore thumb in OO code. String and array handling code invariably ends
up ugly unless you write everything procedural style (and then you have other
issues).

\- Sort() cannot be made to sort unicode on windows, regardless of which
parameters you give it. In fact, the only way to sort unicode on windows is by
using the Collator from the intl extension. Part of that is microsoft's fault
by not supporting UTF-8 in the windows API's at all, but PHP isn't helping.

\- If you don't care about windows, the proper way to sort text is first
calling setlocale(LC_COLLATE, "en_US.UTF8") and then passing the
SORT_LOCALE_STRING argument as second parameter to every call to sort(). Ugly,
ugly, ugly.

\- natsort(), aka "natural sort" cannot be used to sort text like a human
would expect, in any context. It always produces invalid results, even for
ANSI codepages. (e.g. try to sort resume, rope and résumé)

\- The use of utf8_decode and utf8_encode is actively harmful in almost all
circumstancces. There is never a good reason to use them, since the very rare
case where you need them iconv or mb_convert_encoding are better suited. Yet,
the PHP documentation doesn't tell you this, causing lots of people to be led
astray (as I once was).

\- Oh yeah, and there are no less than three API's for unicode string
handling, the mb_ functions, the iconv_ functions and the grapheme_ functions.
What's the difference? I don't know, and I really can't be bothered to read
PHP's source to find out.

\- htmlentities() always requires the parameters ENT_QUOTES, "UTF-8" to do its
job securely (well, almost, as it doesn't encode forward slash which OWASP
recommends). Unless you use a wrapper, your code is yet again uglified.

\- The secure way to JSON-encode text is, and I kid you not,
json_encode($data, JSON_HEX_TAG|JSON_HEX_APOS|JSON_HEX_QUOT|JSON_HEX_AMP). Try
typing that three times in a row, I dare you.

\- And finally, mysql is by far the worst database for unicode handling,
because it cannot sort unicode text according to the standard, at all, no
matter what you do. That's not PHP's fault ofcourse, but since I'm bitching...
:)

~~~
krapp
The json_encode one is particularly annoying as you can't even consider
sending JSON to the browser and using it in JS without all the flags on.
_especially_ if you're dealing with user data or scraping websites.

~~~
mikegioia
Just out of curiosity, could you expand on that a little more? I'm currently
in the process of ripping my hair out with json_encode issues.

We send back a json_encoded array containing a property "html" with html
markup to be injected back into a contenteditable div. Originally I had a ton
of problems if there happened to be the invisible unicode character in there
(php's str functions could not find/replace this character no matter what I
tried). However, this is the first I've seen those flags the GP mentioned.

~~~
krapp
If you look up the json_encode function on php.net it lists the flags. As I
understand it there's a difference between the encoding allowed in javascript
and the encoding allowed in JSON which means certain characters which would be
valid in a javascript object don't necessarily work in JSON, so you end up
having to escape everything possible. There's one flag (JSON_ESCAPE_UNICODE)
which doesn't work on the version of PHP I develop on so I ended up applying
code listed in the comments. This also adds some cruft similar to what
google/facebook etc use if you want it. I haven't had any issues with it yet
but, being what it is, there may be a more elegant way to accomplish it.

    
    
       function AsJSON($arr, $cruft=null){
    		
    	//convmap since 0x80 char codes so it takes all multibyte codes (above ASCII 127). 
    	//So such characters are being "hidden" from normal json_encoding
            array_walk_recursive($arr, function (&$item, $key) {  	
            	if (is_string($item)){  
            		$item = mb_encode_numericentity($item, array (0x80, 0xffff, 0, 0xffff), 'UTF-8');
            	}
            });
            
            $JSON = mb_decode_numericentity(
            	json_encode($arr, JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_QUOT | JSON_HEX_AMP), 
            	array (0x80, 0xffff, 0, 0xffff), 
            	'UTF-8'
            );
    
            if(json_last_error() === JSON_ERROR_NONE){ 
    	  return $cruft.$JSON;
    	 	}
    	}
    

You might also consider looking at the ctype_* functions if you haven't.

------
semerda
Does anyone else here find the PHP namespace format horrible and unlike the
standard dot notation?

~~~
wvenable
I hated it till I started using it, now I don't mind. Dot was never used in
PHP because it's the string concat operator. PHP needs a unique operator for
namespaces because the types of symbols (is it a namespace, class, interface,
etc) aren't known at compile time (unlike Java, C#, etc).

~~~
coldtea
> _Dot was never used in PHP because it 's the string concat operator._

So how about them using the -> operator? Most languages that use . for class
method access also reuse it for namespacing.

