Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What PHP 5.5 might look like

nikic.github.com

Post reply on HN
Print view View original

71–80 of 139 posts

Re: What PHP 5.5 might look like

#71

Post by klearvue »

blindhippo wrote: post #54
mjs wrote: post #25

Earlier quoted context omitted.

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 gettin…

Drupal 8 looks very promising with its adoption of Symfony Elements (HttpFoundation, HttpKernel, Routing, ClassLoader, EventDispatcher, DependencyInjection). Presumably it will be easy to integrate with other Symfony stuff and Symfony itself will benefit from the huge Drupal community.

Re: What PHP 5.5 might look like

#72

Post by snorkel »

Conspicuously absent from PHP:

   array_copy()
... in order to copy-by-value on arrays containing references. Currently to do that you have to do a very fragile hack like this:

   $copy = array_flip(array_flip($original));
... which is vulnerable to key-value collisions ... or you have to write your own homebrew array copy-by-value function.

Re: What PHP 5.5 might look like

#73

Post by giulianob »

harisenbon wrote: post #45
mootothemax wrote: post #28

Earlier quoted context omitted.

To be fair, the biggest problem I have with Cake is its ORM; it just feels unnatural to me. You ask for some data, and get back an associative array of values, which you can't do anything with but pass elsewhere. It just lacks a certain sense of OOPiness for me :)

I feel the same way, and I've been trying to get away from Cake for a while, but the fact that everything except the quirkiness of the ORM is so nice that I stick with it. Also, the next version is supposed to redo the ORM to return actual models.

I wonder if the performance will be better or worst though. Creating tons of objects might impact it but they might be able to do more lazy loading to help.

Re: What PHP 5.5 might look like

#74

Post by TazeTSchnitzel »

snorkel wrote: post #72

Conspicuously absent from PHP: array_copy() ... in order to copy-by-value on arrays containing references. Currently to do that you have to do a very fragile hack like this: $copy = array_flip(array_flip($original)); ... which is vulnerable to key-value collisions ... or you have to write your own homebrew array copy-by-value function.

File a bug report :)

Re: What PHP 5.5 might look like

#75

Post by TylerE »

mootothemax wrote: post #29
mjs wrote: post #25

Earlier quoted context omitted.

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?

Plenty of people dislike Drupal, or WordPress, or Magento I can't speak for Drupal or Magento, but WordPress's codebase is a world of pain. I've written a few plugins in the past, and the WordPress code is simply hell to work with.

Drupal is ok, but a bit old-fashioned and quirky. It's highly callback/hook based, which is fine, but it doesn't always have hooks where you need them, in which case it gets pretty ugly.

Magento is on a whole other level of suck. I worked on a highly customized Magento site 3 years ago, and it was the worst experience of my professional career - lousy software and client-from-hades.

The Magento folder structure is just completely insane...some of the templates are like 8 or 9 subfolders deep, and it's the huge mashed up pile of Zend Framework and homegrown MVC, none of which is well documented (Since after all, they want to push you to paid support...)

Oh, and to further cement the suck, the main database tables are in EAV form. Tons of fun to be had.

Re: What PHP 5.5 might look like

#76

Post by arvidj »

brusch wrote: post #27
maurimtl wrote: post #10

No 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.

Disclaimer: I am working for a shop with much PHP knowledge. There are some really nice frameworks for PHP - for example we are using Yii ( http://www.yiiframework.com/ ), Symfony ( http://www.symfony-project.org/ ) and Flow3 ( http://flow3.typo3.org/ ). I was using Yii in one of my projects and it worked really nice (altough I can't compare it to Rails or Django, because I have no experience with those).

Can you tell us more about your experiences with FLOW3? I work a TYPO3-shop, but hadn't had the chance to use neither ExtBase or FLOW3 much, but it looks exciting, at least after some superficial glances.

Re: What PHP 5.5 might look like

#77

Post by Smerity »

geon wrote: post #60
Smerity wrote: post #6

The 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.

One major disadvantage with so many functions is the cluttered global namespace[1]. PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace, I'd be wary of adding more. Mind you, I'm well aware that this feeling could just be as I'm primarily a Python coder -- in PHP, you perform array_keys($xyz) whilst in Python it's xyz.keys(). Whilst you might consider Python as cheating by pushing all the functions onto the objects, it results in a far happier global namespace[2].

As far as list comprehensions, I tend to find list comprehensions the readable and self documenting, at least in Python where I most commonly see them. If nothing else, what is the ordering of the arguments for the equivalent non list comprehension? With list comprehensions you don't have that impedance.

  // Python example with filter vs list comprehension
  // Filter requires you to remember the ordering --
  // and does it filter on True or False?
  filter(lambda x: x % 2 == 0, range(10)) --> 0 2 4 6 8
  // The list comprehension is self documenting
  [x for x in range(10) if x % 2 == 0] --> 0 2 4 6 8
I can also convert the majority of list comprehensions into English quite easily -- "output x for each x in range(10) if x is divisible by 2" (though it may be cleaner if it was "for each x in range(10) [output x] if x is divisible by 2").

[1]: http://php.net/quickref.php

[2]: http://docs.python.org/library/functions.html + http://docs.python.org/library/exceptions.html

Re: What PHP 5.5 might look like

#78

Post by DomBlack »

masklinn wrote: post #62
DomBlack wrote: post #56

Earlier quoted context omitted.

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.

> The problem with it in it's current form is it does not allow for an application pepper. Considering: * no password hash algorithm I know of supports peppers * that the API allows providing a custom salt I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt…

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText);

The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper.

The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code.

If your database is stolen, but your application code is safe the pepper increases the complexity of brute forcing, as they need to work out what the pepper is

Re: What PHP 5.5 might look like

#79

Post by gurkendoktor »

> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them.

Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software?

Or does this just mean that noone will actively test the binaries on XP anymore?

Re: What PHP 5.5 might look like

#80

Post by Killswitch »

andrewjshults wrote: post #53
mootothemax wrote: post #33

Earlier 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. 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 autolo…

Okay, so a bunch of personal preferences that don't actually matter in the real world? Thanks for your insight, but it does not make CodeIgniter bad.

> frameworks that were built with PHP 5.3 in mind.

Well no crap, CodeIgniter is built for newbies in mind, people who don't have up to date PHP installs because their shared hosting doesn't keep it THAT up to date.

The newest versions of CodeIgniter are VERY good, and just like the haters of PHP, you're just hating on versions of CodeIgniter that are at least 3 versions old. Learn the updated system, then base your claims on that, not something you looked at 2+ years ago.

Post reply on HN