17 ms·
New Features in PHP 5.6
- dhoulb 13y agoWould 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.
- SDGT 13y agoYou can already do this by using a magic setter that blows out an exception whenever its called for whichever variables you denote. A little hacky, but it does indeed prevent setting of certain vars in your classes.
- wvenable 13y agoActually, even easier than SDGT's or krapp's suggestions is to declare your properties private or protected and use a magic getter to expose those properties as public readonly. It's so easy to do that a readonly keyword seems unnecessary.
- krapp 13y agoI 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){ //... } } }
- krapp 13y agoI just noticed some errors in this but the basic gist works... I shouldn't have added the isset checks, those would prevent it from throwing the exceptions -_-
- datphp 13y agoYour 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 13y agoYes, thank you. I noticed the problem after it was too late to edit. Slightly embarrassing.
- semerda 13y agoDoes anyone else here find the PHP namespace format horrible and unlike the standard dot notation?
- wvenable 13y agoI 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 13y ago>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.
- poobrains 13y agoAny word on when all functions will be UTF-8 safe?
- jcampbell1 13y agoOther 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.
- Zancarius 13y agostrlen and strpos are two fairly commonly used functions that come to mind.
- desas 13y agoUse mb_strlen and mb_strpos instead where the string may contain multibyte characters.
- Zancarius 13y agoOr patchwork/utf8 [1] since it handles fallback in the event mb_* isn't installed and can utilize several other libs. [1] https://github.com/nicolas-grekas/Patchwork-UTF8 https://github.com/nicolas-grekas/Patchwork-UTF8
- acabal 13y agoPretty often. Yes you can use mb_* functions everywhere but not all string functions have an mb_* counterpart, and forget just once and you risk blowing up the entire rest of the request. Not to mention times when you have to use a 3rd party library that doesn't bother with mb_*. Native UTF is such an important thing... I know it's tough to implement, but come on guys!
- 13y ago
- leeoniya 13y agoi would love to see them make an explicit BC break and fix everything listed at http://phpsadness.com/ http://phpsadness.com/
- shocks 13y agoYeah, because that worked out SO well with Python… ;P
- jmccree 13y agoIt amuses me people want PHP to follow the path of Python or Perl. On the latest version of Ubuntu: PHP 5.5, Python 2.x Perl 5.x. PHP has gradually improving, adding functionality, and spreading minimal BC breaks over a long period. If PHP had went the PHP 6 route back round ~08, it'd likely be split into two projects already, splitting up the community with it.
- wvenable 13y agoIt happened with PHP4 -> PHP5 already. That was a huge split.
- wvenable 13y agoIf 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 13y agoThe 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.
- agumonkey 13y agoSure PHP had a lot of catch-up to do, but they're really on a fast pace these days.
- mildtrepidation 13y agoThis 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 13y agoNot 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.
- agumonkey 13y agoFrom a distance PHP is splitting cells. People added tools to its eco system, and practices based on pseudo-Java OOP. See PSR code style that basically forbids PHP to be PHP, no inline formatting, split lib as side-effect free and 'main' .. The people behind this movement will probably have integrated the new language construct very soon. So instead of Frankenstein I see a two-headed organism.
- coldtea 13y agoThe arguments in the linked email of some Ilia Alshanetsky regarding the shorthand array syntax are incredibly dense...
- foldor 13y agoI'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 13y agoThe 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.
- asnyder 13y agoI 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.