[deleted]
What PHP 5.5 might look like
51–60 of 139 posts
Re: What PHP 5.5 might look like
#5217 years old and a PHP Internals tinkerer... Awesome work Nikita, keep it up!
As someone who has worked with him for quite some time, all I can say is so very much agree. He blows me away left and right with his knowledge, ability and maturity (especially when it comes to code decisions). He's more senior than most developers that I know...
So very much agree, keep it up!
Re: What PHP 5.5 might look like
#53Earlier quoted context omitted.
Please don't recommend CodeIgniter. I'm not normally one for swathing "x is bad" judgements, but CI is simply not in the same league as the other frameworks you mentioned.
Please don't recommend CodeIgniter. I'm not normally one for swathing "x is bad" judgements, but CI is simply not in the same league as the other frameworks you mentioned. I wouldn't have a few years ago, but the current version seems decent enough. Out of interest, what're your main complaints with it? I'm not a huge fan of CI, but would prefer it to my personal bugbear, CakePHP.
Having taken over a project that uses CI at it's core, I've found a number of things that definitely put it in a league below frameworks that were built with PHP 5.3 in mind.
* Way too much magic - everything (libraries, models, etc.) is globbed onto a superglobal class, which breaks auto-complete in IDEs and in general makes debugging harder
* No proper autoloader (PSR-0 style) - the built in autoloader can't autoload anything that doesn't fit into the CI world which tends to lead to unnecessarily large classes (anything that isn't a model gets lumped into a library)
* Setting up routes gets messy fast (it's all defined as a single associative array)
* No built in template system (which, in my experience, encourages bad behavior in views)
Re: What PHP 5.5 might look like
#54No matter how much PHP is improved upon, until there is a serious contender framework for it like Rails or Django, PHP will continue its route to extinction. Dinosaurs were once big and powerful. They dominated the landscape. They don't exist anymore.
PHP frameworks are pretty decent, and widely liked (if not loved). Though for some reason this doesn't apply to PHP applications: plenty of people dislike Drupal, or WordPress, or Magento. I'm not sure if there's an equivalent situation across languages--does Ruby or Python have loved frameworks and libraries, but unloved (though widely-used) applications?
Wordpress (as stated earlier) is a gong show. I do think people use Wordpress in far too many use cases where other solutions would work better. If you're a designer type with limited code knowledge, or an IT goon who can't really code but can script, Wordpress is often a good fit. But any experienced software developer is going to take one look at the internals and immediately close the editor. I do hear it's getting better, but it's been a while since I last looked at it.
Drupal is an odd duck - it's a framework with a built in CMS. It's immensely powerful for many developers who put the time in to learn it, but the experience is often jarring for traditional "object oriented" developers so they come away with a bad taste in their mouth: "no objects? this is icky!"
Of all the major PHP projects, Drupal seems to be the one embracing good software architecture - Drupal 8 looks to be amazing. It's come a long way from the days of Drupal 5.
Re: What PHP 5.5 might look like
#55[deleted]
If you are fine running a decade+ old OS, chances are you don't have a dire need to run a bleeding edge version of PHP locally.
Re: What PHP 5.5 might look like
#56I think a standard password hash API is a good thing (there was a proposal for such a thing for Python recently on -ideas, though it was essentially rejected in favor of recommending/using passlib), but I'm wary of having default cost factors, that seems unwise: what are the defaults, how are they decided to be ok, and more importantly in what context are they updated over time (and based on what data)?
The problem with it in it's current form is it does not allow for an application pepper.
Also I'd prefer it to support scrypt as well as bcrypt.
Re: What PHP 5.5 might look like
#57The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…
I agree keyword arguments are a better solution (but probably harder to implement).
Right now this is how I do this:
function salute($user, array $options = null) {
$options = (array) $options + array('shout' => false);
$salutation = "Hi $user!";
if ($options['shout']) $salutation = strtoupper($salutation);
return $salutation;
}Re: What PHP 5.5 might look like
#58Earlier quoted context omitted.
Please don't recommend CodeIgniter. I'm not normally one for swathing "x is bad" judgements, but CI is simply not in the same league as the other frameworks you mentioned.
Tell us why! With the low memory overhead, built-in cache, Active Record (+PDO support) and easy-to-understand MVC approach, I think it is the best framework for writing small to medium-sized web applications. CI is not Zend, but nothing prevents you from using the Zend libraries with a small CI Library wrapper - I have done so many times in the past, and it works great.
CI gives you very little, and what it gives you is mostly categorically broken. The total lack of post-redirect-get and insane choices on the session data front meant I was using a custom session storage library I wrote instead of the bundled one.
We had issues where the router and loader were not playing nicely at all - we were using the 404 override option in order to do some custom routing (as the router was not flexible enough for even a very basic CMS). However because of how messy the routing code is, and how much of a hack the 404 override was (last time I checked there were several open bugs regarding this on their tracker, some over a year old and completely untouched), it completely blitzed the loaded libraries, so we had to add in more hacks to dodgily clear the cache of loaded libraries and re-run the loader in order to have them available. The only other way to do this would have been to modify the core loader to fix the bug there (but we didn't want to modify core code to make it easier to keep up to date with framework changes), or completely rewrite the router (which really needs to be done, it's a mess).
The database abstraction code is very kludgy and basically useless for anything beyond utterly, utterly basic use cases (there's a reason it's low overhead - it's low everything, including functionality!)
That's just a few of the things we ran into. By the time we went to production I estimate that out of the maybe 30% of CodeIgniter we were actually using for our project, I had re-implemented as custom libraries maybe a third of that amount just to get some sane behaviour, and work around long-standing bugs. Overall I got the feeling that the framework had no solid direction, some of the core components (most critically the loader and router) were quite obviously piles of hacks rather than having been designed and engineered, and honestly the framework was not really much more re-usable or robust than our own custom in-house one. I know it's a very common developer hubris to think you could write your own framework and do a better job, but in the case of CodeIgniter I can confidently make that claim.
On the more technical and abstract side, it's insane that it doesn't use standard PSR loading (so any other library you want to use you have to write a custom wrapper), and the guidance on making re-usable libraries / modules / packages (I can't even remember the right terminology, they use these words in strange ways) is... unclear at best. It uses globals, it's tightly coupled, everything a decent framework should categorically not be. Overall I would say that the level of technical ability on people using and contributing to CI is very low, and most people I've spoken to that think it's great haven't actually used any other framework (which is, frankly, endemic of a large portion of the PHP-using world)
Edit: Also if you care about overhead, you're not writing what I would call a small to medium sized application! Any framework out there worth its salt (and many that are not) will be able to run your application just fine, it's extremely unlikely that the PHP layer will be the bottleneck unless you're writing really terrible code or using a really terrible framework.
Re: What PHP 5.5 might look like
#59This is just a "would be nice" sort of post right? The main feature I'd want (list comprehensions) seems to be just a single programmer's guess at an upcoming feature with no real evidence.
Pay close attention to the "status" listed under each header. Some of these features have already landed in master, and others are still in various states of proposal. The author links to the official RFC for most of the proposed features.
I'm not sure if the list comprehensions feature has made it past the mailing list though.
Re: What PHP 5.5 might look like
#60The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…
> I'm not sure why they're adding the array_column function
Isn't the function call much more readable than the comprehension?
At least as a beginner, I found the large set of built in functions to be one of the strongest points of PHP.