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

The new PHP

programming.oreilly.com

Post reply on HN
Print view View original

141–150 of 203 posts

Re: The new PHP

#141

Post by dtech »

uxp wrote: post #111
nikic wrote: post #35

Earlier quoted context omitted.

PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x series improves the language mostly through additions. I think that's good. PHP has been missing a number of things that are now present. However that doesn't work forever, at some point you need to clean up some of the old stuff. That's why a PHP 6 release is planned in the near future (i.e. somewhere in the next three years ^^).

The very first programming book I bought was "PHP6 and MySQL5" by Larry Ullman. I bought that one specifically because I had another job (career, really) and I knew it was going to take a while before I really got into programming and I didn't want to buy a book that was going to be out of date in 2 years. That book is now 6 years old, out of date, and PHP6 is still not released. Maybe 6 is just an unlucky number wit…

The goal for PHP6 is basically to provide good unicode support (strings internally as unicode etc.)

However due to problems and internal conflicts the effort was stopped a few years ago and there has been no progress since.

If this goal hadn't been stated PHP 5.3+5.4 would probably have been PHP 6 (they have some major new features). Core API cleanup never has been (and it doesn't look like it will soon be) a goal for a future release, unfortunately.

Re: The new PHP

#142

Post by dtech »

jdbevan wrote: post #67
rubiquity wrote: post #17

> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style. "The new Java" It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I th…

There's some discussion on the RFCs and mailing lists about creating new backwards-incompatible OO APIs for the core libraries which would eventually replace some of the legacy mess.

Can you link the RFC's/Threads? When you're not familiar with the PHP dev ecosystem it can be hard to find the meaningful stuff.

Re: The new PHP

#143

Post by dmiladinov »

Kiro wrote: post #138
anaphor wrote: post #137

Earlier quoted context omitted.

Do you really think tacking on more badly designed features makes PHP better? PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist, that is something a compiler should be doing. Google "closure conversion".

> PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist Can you give an example? I googled "closure conversion" but didn't understand.

In order to use variables from the scope that the anonymous function came from, you have to explicitly import them into the anonymous function with the use[1] block:

    public function getTotal($tax)
    {
        $total = 0.00;
        
        $callback =
            function ($quantity, $product) use ($tax, &$total)
            {
                $pricePerItem = constant(__CLASS__ . "::PRICE_" .
                    strtoupper($product));
                $total += ($pricePerItem * $quantity) * ($tax + 1.0);
            };
        
        array_walk($this->products, $callback);
        return round($total, 2);
    }
In other languages that have true closures, the anonymous function "closes over" the lexical scope in which it was declared.

[1]: http://www.php.net/manual/en/functions.anonymous.php

Re: The new PHP

#144

Post by anaphor »

Kiro wrote: post #138
anaphor wrote: post #137

Earlier quoted context omitted.

Do you really think tacking on more badly designed features makes PHP better? PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist, that is something a compiler should be doing. Google "closure conversion".

> PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist Can you give an example? I googled "closure conversion" but didn't understand.

It is an algorithm used in compiling languages like Scheme where you calculate the set of free variables in a function and then create a closure (a function pointer and an environment, which is basically a way to lookup free variables). PHP requires you to do this by hand with the "use" keyword, e.g. use($a, $b, $c) where $a, $b, and $c are free variables (that is they are not bound in the current scope). I see no reason why PHP couldn't be doing this for you other than that the devs are lazy.

Re: The new PHP

#145

Post by tsm »

Kiro wrote: post #138
anaphor wrote: post #137

Earlier quoted context omitted.

Do you really think tacking on more badly designed features makes PHP better? PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist, that is something a compiler should be doing. Google "closure conversion".

> PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist Can you give an example? I googled "closure conversion" but didn't understand.

Example 3 here: http://us1.php.net/manual/en/functions.anonymous.php

The necessity of `use` is, IMHO, ridiculous.

Re: The new PHP

#146

Post by jrs235 »

nikic wrote: post #35
rubiquity wrote: post #17

> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style. "The new Java" It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I th…

PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x series improves the language mostly through additions. I think that's good. PHP has been missing a number of things that are now present. However that doesn't work forever, at some point you need to clean up some of the old stuff. That's why a PHP 6 release is planned in the near future (i.e. somewhere in the next three years ^^).

Sounds like if PHP6 is going to be cleaned up and break backwards compatibility then it really needs to be named PHP+ or named differently so that the less informed nonfollowing developers understand it's not just PHP5 plus some more stuff and therefore it's not backwards compatible.

Re: The new PHP

#147

Post by [deleted] »

Kiro wrote: post #138
anaphor wrote: post #137

Earlier quoted context omitted.

Do you really think tacking on more badly designed features makes PHP better? PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist, that is something a compiler should be doing. Google "closure conversion".

> PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist Can you give an example? I googled "closure conversion" but didn't understand.

[deleted]

Re: The new PHP

#148

Post by indeyets »

dscrd wrote: post #128
indeyets wrote: post #122

Earlier quoted context omitted.

You mean like boris? https://github.com/d11wtq/boris

Looks good, but here's the practical question: Can I enter this REPL with all the libraries and models of my web framework loaded so that I can query a model through it, modify the object and save?

https://github.com/d11wtq/boris#using-boris-with-your-applic...

Re: The new PHP

#150

Post by encoderer »

awestroke wrote: post #20
mgkimsal wrote: post #14

Earlier quoted context omitted.

Make the "stdout == response body" an explicit option Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be. "== should work like ===". Why? If you want ===, use ===. Bu…

1: "Explicit option" means it's still possible, but shouldn't better practices be encouraged? Anything to push developers away from interleaving logic and templates 2: PHP, however, has types. == is wildly unpredictable

> PHP, however, has types. == is wildly unpredictable

It's deterministic. It is by definition not unpredictable.

http://us3.php.net/manual/en/types.comparisons.php

Post reply on HN