PHP 5.3 and Mjölnir
-
Alexey Zakhlestine
PHP 5.3 and Mjölnir
Thu July 02 2009 09:35:08 UTCHi.
As everyone, probably, already knows PHP 5.3 was released today. It is
a major release, which brings a lot of new features, which can be
useful to us. I will write down some of them with comments on
usefulness.
1) Closures/Lambda-functions
In 5.2 and earlier callbacks could be either runtime-compiled
(create_function()), which is slow, or you had to define method and
pass it's name, which clutters namespace. Anyway, both these cases
lack scope-inheritance which limits their usefulness.
5.3 has true closures, which allows usage of functional patterns in
php code. First thing which comes to mind is work with arrays: map,
reduce, filter, etc. instead of foreach-cycles. But even more
interesting pattern is context-aware callbacks. There's a nice example
of such callback here:
http://www.phparch.com/main/news/view/29/Poll__Five_PHP_5_3_Reasons_to_Make_You_Switch
function loadData($url, $handler)
{
$handler(file_get_contents($url));
}
function sendPageTo($email, $url)
{
loadData($url, function($data) use ($email) {
mail($email, "Here's your data", $data);
});
}
In general, closures give us a whole new dimension of reusability.
2) Namespaces
This, probably, is the most discussed feature of PHP 5.3. I'll be
short: we have use-case for this. Current naming pattern in
Midgard-MVC leads to extremely long class-names. Switching to
namespaces would make code more compact, more readable and less
fragile.
Also, there is an interesting related topic: using exception-model
proposed by php.standards initiative. See:
http://news.php.net/php.standards/2
Basic idea is, that application should inherit it's exceptions from
the standard SPL-exceptions while giving them the same name (but in
it's own namespaces)
namespace Midgard;
class RuntimeException extends \RuntimeException();
after that, framework-developers can use usual "throw new
RuntimeException();" in code, and application developers can
distinguish between exceptions which come from different frameworks:
try {
// some code
} catch (Midgard\RuntimeException $e) {
// Midgard-specific handling
} catch (PEAR2\RuntimeException $e) {
// PEAR-specific handling
} catch (RuntimeException $e) {
// Generic handling
}
3) Late Static Binding (aka LSB)
This is a major step ahead in PHP's dynamic nature. My favourite
example for this feature is ActiveRecord-like classes. In PHP 5.2 it
was possible to define ActiveRecord class with generic methods for
loading, creating, updating of database-records. After that, it was
possible to inherit another class from it, while not defining class
body. Like this, literally:
class Book extends ActiveRecord {}
$book = new Book();
$book->name = 'name';
$book->author = 'author';
$book->save();
ActiveRecord's save() method, in this case, would detect object's
class at runtime and figure out what to do dynamically. That's a
common knowledge and is really useful. But… It was impossible to do
the same with class-methods (aka "static" methods) until now. Class
methods couldn't detect the class they were called on. So, in 5.2 it
was impossible to implement generic method for the following case:
$books = Book::find_all();
ActiveRecord's find_all() method would only know, that it belongs to
ActiveRecord and wouldn't know anything about Book class.
PHP 5.3 introduces 2 things in this regard:
* get_called_class() function, which returns class, on which the call
was made ("Book" in my example)
* "static::" caller in addition to "self::". "static::" propagates the
call-chain to the parent, so __CLASS__ constant would return child's
class name.
check http://docs.php.net/manual/en/language.oop5.late-static-bindings.php
for more details
4) Garbage collector for cyclic references
This one is simple. In PHP 5.2 and earlier, if you had situation where
object $a has reference to object $b, while, at the same time, $b has
reference to $a the memory they occupy would never be freed (until
program termination). This limitation, effectively, killed possibility
of having complex long-running php processes. Sooner or later, process
would take all available memory and die("in agony").
PHP 5.3 fixes this and gives us ability to write complex daemons in php.
5) Efficient data-structures in SPL
Starting with PHP 5.3, SPL (Standard PHP Library) gains real value.
Until now it was a set of small, helpful, but mostly under-the-hood
goodies. 5.3 brings fast implementations of the most common
data-structures:
* Doubly-linked List (SplDoublyLinkedList)
* Stack (SplStack)
* Fixed-size Array (SplFixedArray)
* Heap (SplHeap, SplMaxHeap, SplMinHeap)
* Queue (SplQueue)
* Priority Queue (SplPriorityQueue)
You can see more about these here: http://docs.php.net/spl
Usual speed difference between this implementation and implementation
in PHP is several tens times, at least. They are really fast.
6) New default extensions: PHAR (PHP Archive), enchant
(spell-checking), intl (unicode-compliant collation + ICU-based
formatting)
PHAR let's us pack a library or an application into a single
"project.phar" file. That is convenient for distribution and gives
speed-boost if you use phar and APC at the same time (APC can use more
efficient cache-strategy, when application is packed as a single-file
on filesystem level).
Enchant is a generalized extension, which can work with the majority
of spell-checking backends. This includes ispell, aspell and even
AppleSpell
intl (aka Internationalization extension) is a binding to ICU
(International Components for Unicode) library. It provides means for
working with unicode-compliant locale's, proper unicode-compliant
sorting and unicode-compliant formatting of dates and numbers. That's
a necessity in 21-st century and POSIX-locales are way outdated to
handle complex cases properly.
Given all benefits PHP 5.3 gives us, as developers, I propose to
switch development of Mjölnir to PHP-5.3+ only compatibility. As a
result we can get a cleaner, faster and more powerful code. Mjölnir
still needs some time before it can be commonly used in production and
I have a feeling, that all main distributions will include PHP-5.3
until that time.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 09:50:11 UTCOn 2.7.2009, at 12.24, Alexey Zakhlestin wrote:
> Given all benefits PHP 5.3 gives us, as developers, I propose to
> switch development of Mjölnir to PHP-5.3+ only compatibility. As a
> result we can get a cleaner, faster and more powerful code. Mjölnir
> still needs some time before it can be commonly used in production and
> I have a feeling, that all main distributions will include PHP-5.3
> until that time.
I have to disagree.
Mjölnir will be released within few months. Basically most of the
stable server distros will not include PHP 5.3 in a long time.
Also Midgard 2 is still more or less untested in real environments.
So if we have bugs we really don't know where they originate from.
With PHP 5.3 we have nice features but really we cannot make that the
one and only supported PHP version.
Best regards
Tero Heikkinen
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 09:55:05 UTCAlexey Zakhlestin wrote:
<snip>
Very good, you can basically just copy-paste this as mRFC and then we
can vote.
Though we need to update the coding standards document (or actually make
a new one since ragnaroek is still going to stay here for a long while).
/Rambo
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 11:25:05 UTCAlexey Zakhlestin writes:
Hi!
> 5) Efficient data-structures in SPL
>
> Starting with PHP 5.3, SPL (Standard PHP Library) gains real value.
> Until now it was a set of small, helpful, but mostly under-the-hood
> goodies. 5.3 brings fast implementations of the most common
> data-structures:
>
> * Doubly-linked List (SplDoublyLinkedList)
> * Stack (SplStack)
> * Fixed-size Array (SplFixedArray)
> * Heap (SplHeap, SplMaxHeap, SplMinHeap)
> * Queue (SplQueue)
> * Priority Queue (SplPriorityQueue)
<offtopic>
I know this is pecl-dev topic, but couldn't ZE2 guys make *proper* GLib
bindings *once* ?
Not only those are implemented there for years and used by (at least)
GTK and Python, but
also Midgard itself could benefit *a lot* :)
</offtopic>
> Given all benefits PHP 5.3 gives us, as developers, I propose to
> switch development of Mjölnir to PHP-5.3+ only compatibility. As a
> result we can get a cleaner, faster and more powerful code. Mjölnir
> still needs some time before it can be commonly used in production and
> I have a feeling, that all main distributions will include PHP-5.3
> until that time.
Mjolnir is due in 3 months.
Do we have any distribution list which are going to support PHP 5.3 by
this time?
I suspect Ubuntu 9.10 could include it, but what about the rest?
Keeping high-tech state is a cool thing, but availability is serious issue.
I would propose start PHP 5.3+ support since 10.03. But this one also
depends when we are going to release next LTS Midgard2 version.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 11:30:07 UTCHi,
On Thu, Jul 2, 2009 at 2:15 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> Keeping high-tech state is a cool thing, but availability is serious issue.
> I would propose start PHP 5.3+ support since 10.03. But this one also
> depends when we are going to release next LTS Midgard2 version.
The point here mostly is that we either have to make the jump to
namespaces now, or it won't be done with midcom3.
> Piotras
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 11:45:05 UTCHenri Bergius writes:
> Hi,
>
> On Thu, Jul 2, 2009 at 2:15 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
>> Keeping high-tech state is a cool thing, but availability is serious issue.
>> I would propose start PHP 5.3+ support since 10.03. But this one also
>> depends when we are going to release next LTS Midgard2 version.
>
> The point here mostly is that we either have to make the jump to
> namespaces now, or it won't be done with midcom3.
I can understand it only (and only) if midgard-php extension is going to
stay PHP 5.2.
In any other case, there's no any sense to work on "Midgard is easy to
install" plan.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 11:55:06 UTCHi,
On Thu, Jul 2, 2009 at 2:34 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> I can understand it only (and only) if midgard-php extension is going to
> stay PHP 5.2.
Yes, that makes sense.
Can we anyway support stuff like late static bindings via some IFDEF?
That'd make midgard_article::new_query_builder() possible.
> Piotras
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 12:05:06 UTCHenri Bergius writes:
> Hi,
Hi!
> On Thu, Jul 2, 2009 at 2:34 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
>> I can understand it only (and only) if midgard-php extension is going to
>> stay PHP 5.2.
>
> Yes, that makes sense.
>
> Can we anyway support stuff like late static bindings via some IFDEF?
> That'd make midgard_article::new_query_builder() possible.
We must. This is very annoying issue so far and should be fixed ASAP.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 12:30:07 UTCOn Thu, Jul 2, 2009 at 3:34 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> Henri Bergius writes:
>> Hi,
>>
>> On Thu, Jul 2, 2009 at 2:15 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
>>> Keeping high-tech state is a cool thing, but availability is serious issue.
>>> I would propose start PHP 5.3+ support since 10.03. But this one also
>>> depends when we are going to release next LTS Midgard2 version.
>>
>> The point here mostly is that we either have to make the jump to
>> namespaces now, or it won't be done with midcom3.
>
> I can understand it only (and only) if midgard-php extension is going to
> stay PHP 5.2.
> In any other case, there's no any sense to work on "Midgard is easy to
> install" plan.
In case it wasn't clear: I was talking only about Midgard-MVC, not
about midgard-php
midgard-php can (and should) stay the way it is, for now.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] PHP 5.3 and Mjölnir
Thu July 02 2009 12:50:06 UTCOn 2.7.2009, at 15.19, Alexey Zakhlestin wrote:
> In case it wasn't clear: I was talking only about Midgard-MVC, not
> about midgard-php
> midgard-php can (and should) stay the way it is, for now.
Midgard-MVC is in production use :) Even with more than one site (and
on plenty of dev servers).
So I'm also against that Midgard-MVC is made PHP 5.3 only.
For who are we trying to make this Midgard-MVC for example? By making
it dependent of PHP 5.3 it basically requires that you must start
compiling PHP 5.3 by hand. It effectively renders out most of the new
comers out and is a big pain for the current users of Midgard-MVC. I
think that we can start thinking transitioning with next year's
releases.
I've battled one year with "stable debian's" PHP 5.2 (that has memory
abuse issues), ragnaroek beta and MidCOM3's first more or less usable
versions. And I can tell that developing of software will become very
interesting when there are many bits and pieces that are beta and
unstable. And if we now move to 5.3 we'll add yet another moving
piece to this stack. So basically I think that we should rely on the
old good 5.2 and start thinking of the switch when the other parts of
the software are more mature.
Midgard and Midgard-MVC has been always very hard to install. Why to
make things even more complicated?
Best reagards
Tero Heikkinen (who is trying to fix MVC's gettext-i18n that is
broken with dynamic loads)
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
