Squirrelmail and PHP6

View: New views
5 Messages — Rating Filter:   Alert me  

Squirrelmail and PHP6

by Steve Brown-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

This has come up on IRC a few times in the last couple of days, and I
figured it should be mentioned here as well.

PHP6 is making some major changes in terms of removing old
functionality that will have a big impact on Squirrelmail.  Most of
the changes are being tagged as deprecated in the 5.3 series.  Some
items have already been mentioned on the list, such as removing
session_unregister.  This article contains a fairly complete list of
the changes:

http://www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html

The big changes that I've noticed are removing of ereg from a stock
PHP build and dropping support for the PHP4 object model.  Ereg is
used pretty extensively in SM.  PHP4 objects are also used throughout
for message delivery, i18n/l10n, and templates in DEV.  I don't know
what behavior 5.3 exhibits with a PHP4 object, but we know it will be
dropped in PHP6.

Just wanted to make others aware of the coming doom. ;)

SB

------------------------------------------------------------------------------
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Squirrelmail and PHP6

by Paul Lesniewski :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 7/23/09, Steve Brown <sbrown25@...> wrote:

> This has come up on IRC a few times in the last couple of days, and I
> figured it should be mentioned here as well.
>
> PHP6 is making some major changes in terms of removing old
> functionality that will have a big impact on Squirrelmail.  Most of
> the changes are being tagged as deprecated in the 5.3 series.  Some
> items have already been mentioned on the list, such as removing
> session_unregister.  This article contains a fairly complete list of
> the changes:
>
> http://www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html
>
> The big changes that I've noticed are removing of ereg from a stock
> PHP build and dropping support for the PHP4 object model.  Ereg is
> used pretty extensively in SM.

There is a tracker item open to document that this needs to be done.

>  PHP4 objects are also used throughout
> for message delivery, i18n/l10n, and templates in DEV.  I don't know
> what behavior 5.3 exhibits with a PHP4 object, but we know it will be
> dropped in PHP6.

I haven't looked into it much myself yet, but it looks to me like
there is some confusion and shortage of accurate information about
this.

The article you pointed to as well as the PHP manual state that "var"
will be (is) an alias for "public" for member variables.  That means
PHP4 member variable syntax will continue to work in PHP6.

This article:

http://www.linux-mag.com/id/7433/2/

claims that "var" won't work, but only by showing a code example, so I
am inclined to think this article is actually wrong.  Poor reporting.

That article also implies that visibility qualifiers will be required
when defining member functions, but I don't see mention of that
anywhere else, including in the article you found.

So I am currently lead to believe that the PHP4 object syntax WILL NOT
break in PHP6.  Too bad there's not somewhere with some *accurate*,
definitive information about this.

------------------------------------------------------------------------------
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Squirrelmail and PHP6

by Tomas Kuliavas :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Paul Lesniewski wrote:
On 7/23/09, Steve Brown <sbrown25@gmail.com> wrote:
> This has come up on IRC a few times in the last couple of days, and I
> figured it should be mentioned here as well.
>
> PHP6 is making some major changes in terms of removing old
> functionality that will have a big impact on Squirrelmail.  Most of
> the changes are being tagged as deprecated in the 5.3 series.  Some
> items have already been mentioned on the list, such as removing
> session_unregister.  This article contains a fairly complete list of
> the changes:
>
> http://www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html
>
> The big changes that I've noticed are removing of ereg from a stock
> PHP build and dropping support for the PHP4 object model.  Ereg is
> used pretty extensively in SM.

There is a tracker item open to document that this needs to be done.

>  PHP4 objects are also used throughout
> for message delivery, i18n/l10n, and templates in DEV.  I don't know
> what behavior 5.3 exhibits with a PHP4 object, but we know it will be
> dropped in PHP6.

I haven't looked into it much myself yet, but it looks to me like
there is some confusion and shortage of accurate information about
this.

The article you pointed to as well as the PHP manual state that "var"
will be (is) an alias for "public" for member variables.  That means
PHP4 member variable syntax will continue to work in PHP6.

This article:

http://www.linux-mag.com/id/7433/2/

claims that "var" won't work, but only by showing a code example, so I
am inclined to think this article is actually wrong.  Poor reporting.

That article also implies that visibility qualifiers will be required
when defining member functions, but I don't see mention of that
anywhere else, including in the article you found.

So I am currently lead to believe that the PHP4 object syntax WILL NOT
break in PHP6.  Too bad there's not somewhere with some *accurate*,
definitive information about this.
You both see higher level changes and miss the basic ones. PHP6 changes string variables and operations. Both articles mention unicode.semantics setting, but it was removed more than one year ago. There is no way to turn that thing off. SquirrelMail does not have lots of dependencies, because lots of things are done in basic PHP functions. These basic functions are changed in PHP6.

SquirrelMail code written for PHP6 won't be compatible with PHP 5.2.0 and older PHP versions. Code often works with strings in bytes and switches to work with characters only when specifically written to do so in i18n code. PHP6 does not like it. PHP6 strings operate with characters. Last time I've checked decoding and otp code was fubar in PHP6.

--
Tomas

Re: Squirrelmail and PHP6

by Steve Brown-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> So I am currently lead to believe that the PHP4 object syntax WILL NOT
> break in PHP6.  Too bad there's not somewhere with some *accurate*,
> definitive information about this.

FWIW, I downloaded and built a snapshot of PHP6 to do some simple
tests (cli only, not through a server).  The following class worked
fine in PHP5 and PHP6:

<?php
class foo {
  var $bar = 'hello world';

  function foo() {
    echo $this->bar;
  }
}
$a = new foo();
?>

Output was as expected: 'hello world'.  However, the following class
taken from the PHP docs raised some strict PHP warnings:

<?php
class A
{
    function foo()
    {
        if (isset($this)) {
            echo '$this is defined (';
            echo get_class($this);
            echo ")\n";
        } else {
            echo "\$this is not defined.\n";
        }
    }
}

class B
{
    function bar()
    {
        A::foo();
    }
}

$a = new A();
$a->foo();
A::foo();
$b = new B();
$b->bar();
B::bar();
?>

Output was as follows:

$this is defined (A)
PHP Strict Standards:  Non-static method A::foo() should not be called
statically in - on line 26
$this is not defined.
PHP Strict Standards:  Non-static method A::foo() should not be called
statically, assuming $this from incompatible context in - on line 20
$this is defined (B)
PHP Strict Standards:  Non-static method B::bar() should not be called
statically in - on line 29
PHP Strict Standards:  Non-static method A::foo() should not be called
statically in - on line 20
$this is not defined.

------------------------------------------------------------------------------
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Squirrelmail and PHP6

by Paul Lesniewski :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 7/24/09, Steve Brown <sbrown25@...> wrote:
>> So I am currently lead to believe that the PHP4 object syntax WILL NOT
>> break in PHP6.  Too bad there's not somewhere with some *accurate*,
>> definitive information about this.
>
> FWIW, I downloaded and built a snapshot of PHP6 to do some simple
> tests (cli only, not through a server).  The following class worked
> fine in PHP5 and PHP6:

Thanks, Steve.  So it works as you'd expect (STRICT warnings are a
given - poor coding).... all these articles are completely overblowing
the issue.  PHP4 object syntax does in fact live on in PHP6.

> <?php
> class foo {
>   var $bar = 'hello world';
>
>   function foo() {
>     echo $this->bar;
>   }
> }
> $a = new foo();
> ?>
>
> Output was as expected: 'hello world'.  However, the following class
> taken from the PHP docs raised some strict PHP warnings:
>
> <?php
> class A
> {
>     function foo()
>     {
>         if (isset($this)) {
>             echo '$this is defined (';
>             echo get_class($this);
>             echo ")\n";
>         } else {
>             echo "\$this is not defined.\n";
>         }
>     }
> }
>
> class B
> {
>     function bar()
>     {
>         A::foo();
>     }
> }
>
> $a = new A();
> $a->foo();
> A::foo();
> $b = new B();
> $b->bar();
> B::bar();
> ?>
>
> Output was as follows:
>
> $this is defined (A)
> PHP Strict Standards:  Non-static method A::foo() should not be called
> statically in - on line 26
> $this is not defined.
> PHP Strict Standards:  Non-static method A::foo() should not be called
> statically, assuming $this from incompatible context in - on line 20
> $this is defined (B)
> PHP Strict Standards:  Non-static method B::bar() should not be called
> statically in - on line 29
> PHP Strict Standards:  Non-static method A::foo() should not be called
> statically in - on line 20
> $this is not defined.

--
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donations.php

------------------------------------------------------------------------------
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel