Php

Some measurements on Arrays vs ArrayObjects found among gist users. Just going to bring it here, in case gist dissappears. # php -v PHP 5.3.6 (cli) (built: Mar 17 2011 20:58:15) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies # echo '<?php $s = array(); for($x=0;$x<1000;$x++){ $s[] = array("name"=>"Adam","age"=>35); }; echo memory_get_peak_usage(); ' | php 655040 # echo '<?php $s = array(); for($x=0;$x<1000;$x++){ $o = new ArrayObject; $o->name = "Adam"; $o->age = 35; $s[] = $o;} echo memory_get_peak_usage(); ' | php 887984 # time echo '<?php $s = array(); for($x=0;$x<100000;$x++){ $o = new ArrayObject; $o->name = "Adam"; $o->age = 35; $s[] = $o;} echo memory_get_peak_usage(); ' | php 61010784 real 0m1.448s user 0m1.208s sys 0m0.231s # time echo '<?php $s = array(); for($x=0;$x<100000;$x++){ $s[] = array("name"=>"Adam","age"=>35); }; echo memory_get_peak_usage(); ' | php 33647944 real 0m0.525s user 0m0.429s sys 0m0.092s We can conclude the following at least in PHP 5.6: ...

Chronos is a drop-in library replacement for nesbot/carbon. It provides immutable date/datetime objects. Immutable objects help us to ensure, that DateTime objects aren’t accidentally modified. <?php<br>require 'vendor/autoload.php';<br>use Cake\Chronos\Chronos;<br>printf("Now: %s", Chronos::now());<br>?>

Recently read this article from James Watts: By adopting PSR-2 we can remove or reduce the code we maintain related to enforcing coding standards. As there are common tools, used by the rest of the community, to validate and revise CS issues, without requiring exceptions. james watts Looks like it’s the time to re-write our internal modules with PSR-2 standards in mind. If we want to share them with open-source community, of course ...

So in PHP functions are basically used in two cases: If the programmer doesn’t yet use OOP or if the script isn’t worth using OOP for. The notion of “helper function” or something like that does not seem to exist…(Reminder: Using classes does not mean your code is object-oriented!) So true! But what really got me on this article, was this part: Another tangentially related “standard” practice I feel badly about is the excessive use of doccomments. In most cases phpdoc comments just comment the obvious - at the same increasing the code size by a factor of two or three. I have no problem with doccomments where necessary, but in most cases (at least with well designed code) the behavior should be obvious from the method and parameter names. ...

Input Processing and sanitize (GET/POST/COOKIE) Session Management Database Access without surprises Syntactic sugar for callbacks Template processing XML, HTML, JSON processing These are stuff that PHP should already have in some kind of fast internal c code, but it simply fails to deliver. Frameworks fill the gap. If HHVM provides substantial better alternatives and people use HHVM then Frameworks will use these extensions. Framework code is already filled with edge case handling for different PHP Versions, adding a case for HHVM isn’t a problem. ...