headers
Stan Vass | 1 Aug 2012 01:23

[PHP-DEV] Traits behavior still up in the air in 5.4

I'd like to point out some puzzling behaviors in Traits as they exist in the production releases of PHP 5.4.

----------------------------------------------------------------------------
1. Name collisions between a trait method and a class method using the trait go unreported, the class
silently shadowing the trait method:
----------------------------------------------------------------------------

trait T {
    function foo() { $this->bar; }
    function bar() { echo 'trait'; }
}

class C {
    use T;
    function bar() { echo 'class'; }
}

$c = new C;
$c->foo(); // "class"

Proposed behavior: Fatal error on collision, unless the method is imported with a unique name using the {
... as ... } syntax.

----------------------------------------------------------------------------
2. Using "as" syntax when importing a trait does NOT rename a method, but creates an alias CLONE, the
original method still callable.
----------------------------------------------------------------------------

trait T {
    function bar() { echo 'trait'; }
(Continue reading)

Permalink | Reply | 10 comments |
headers
Pierre Joye | 1 Aug 2012 07:46
Picon
Gravatar

Re: [PHP-DEV] xml ext and & entities

hi!

On Mon, Jul 30, 2012 at 9:13 AM, Stas Malyshev <smalyshev <at> sugarcrm.com> wrote:
> Hi!
>
> I was running PHP tests on my freshly installed CentOS instance and I
> noticed that two XML tests were failing: ext/xml/tests/bug35447.phpt and
> ext/xml/tests/xml011.phpt. Looks like for some reason XML parser when
> parsing something like this: This &amp; that - produces empty string
> instead of "&" when parsing &amp;.
> Any idea why it could be happening? libxml2 is of version 2.7.8 and in
> general it's standard CentOS 6.3, 64-bit.  Does not reproduce on Mac
> with same PHP and same libxml2 version.

Can you try using a stock version of libxml or using the latest version?

I met some issues in the past on Centos because of bad patches applied
to libxml.

Cheers,
-- 
Pierre

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Marr | 1 Aug 2012 08:10
Picon

Re: [PHP-DEV] Traits behavior still up in the air in 5.4

Dear Stan:

On 01 Aug 2012, at 01:23, Stan Vass wrote:

> ----------------------------------------------------------------------------
> 1. Name collisions between a trait method and a class method using the trait go unreported, the class
silently shadowing the trait method:
> ----------------------------------------------------------------------------
> 
> trait T {
>    function foo() { $this->bar; }
>    function bar() { echo 'trait'; }
> }
> 
> class C {
>    use T;
>    function bar() { echo 'class'; }
> }
> 
> $c = new C;
> $c->foo(); // "class"
> 
> Proposed behavior: Fatal error on collision, unless the method is imported with a unique name using the {
... as ... } syntax.

This happens to be 'by design'.

The methods in the class have *always* higher precedence.
This is the same 'overriding' behavior used for inheritance.
From my personal perspective, changing this would lead to a major inconsistency with how subclassing works.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Lester Caine | 1 Aug 2012 08:19
Picon
Favicon
Gravatar

Re: [PHP-DEV] Bringing users along ...

Rasmus Lerdorf wrote:
>> Having just been helping another unsophisticated user, the growing
>> >problem of incompatibility between versions is starting to hit harder.
>> >So can developers please start taking a little more care with the
>> >support of existing users!
> Lester, we get it. Your job is to maintain and support legacy code and
> you are grumpy about it. You have posted about it repeatedly for years.
> And as much as you don't think we do enough, we actually put a lot of
> emphasis on not breaking backward compatibility. But it is always a
> trade off. Every new feature, bug fix or security fix introduces some
> level of backward compatibility issue. We try to minimize those BC
> breaks, but they will continue to happen. You will just have to  find a
> way to manage it.

At the moment it would seem that 'upgrades' are spiralling out of control 
everywhere :(

I'm currently having to buy extra monitors and take them out to site simply 
because some git at M$ has decided that Windows XP can only be used if every 
display has one attached! The bulk of my infrastructure is 'headless' as far as 
the desktop, as the remote displays are only controlled over the network. LINUX 
has added the same 'improvement' so that none of my servers run properly as they 
are attached to KVM's and will no longer boot up with the right screen layout. 
The fix is to replace thousands of pounds worth of hardware :( I can't stop 
windows/linux updates as the local IT people require that they run.

The current raft of PHP problems arise from the fact that "we actually put a lot 
of emphasis on not breaking backward compatibility" seems just to be lip service 
to the real problem ... Taking stuff out in PHP5.4 would be fine if people are 
upgrading from PHP5.3, but they are not. The bulk of the live code is still on
(Continue reading)

Permalink | Reply | 13 comments |
headers
Stas Malyshev | 1 Aug 2012 08:28
Favicon
Gravatar

Re: [PHP-DEV] Bringing users along ...

Hi!

> The current raft of PHP problems arise from the fact that "we actually put a lot 
> of emphasis on not breaking backward compatibility" seems just to be lip service 
> to the real problem ... Taking stuff out in PHP5.4 would be fine if people are 

So what would happen if it would be real BC? I mean, if you want 5.4, we
need to make some changes. Some of these changes will make either
impossible or impractical to support broken code, and some broken code
warnings were actually requested by the users. So I see one of the two ways:
1. Ignore our users asking for warnings on broken code, since somebody
might have problems upgrading when his code is broken.
2. Listen to our users asking for warning on broken code, and prefer
future clean code to old broken one.

Do you see any third way to do? If so, please describe.

> Helping to solve the problem would also help everybody else upgrade TO PHP5.4?

OK, so what help do you require?

> Add to this the fun getting Apache 2.4 configured with PHP and my old framework, 
> it is no wonder I grumpy ... I would much rather be adding functionality and 
> working on NEW stuff than fixing the problems other people leave behind. And I 
> don't need any of the new PHP5.3/44 features to write my own new code.

While I can sympathize with your problems fixing bad code left by other
people, I am not sure how it is relevant on this list - is there
something that people present on this list can help you with? What is it?
--

--
(Continue reading)

Permalink | Reply | 12 comments |
headers
Lester Caine | 1 Aug 2012 08:55
Picon
Favicon
Gravatar

Re: [PHP-DEV] Bringing users along ...

Stas Malyshev wrote:
>> Helping to solve the problem would also help everybody else upgrade TO PHP5.4?
> OK, so what help do you require?
PEAR and PECL that work with PHP5.4 out of the box?
At least the core of PEAR that does not throw strict warnings from a stock 
install of PHP5.4 as E_STRICT is on.

>> >Add to this the fun getting Apache 2.4 configured with PHP and my old framework,
>> >it is no wonder I grumpy ... I would much rather be adding functionality and
>> >working on NEW stuff than fixing the problems other people leave behind. And I
>> >don't need any of the new PHP5.3/44 features to write my own new code.
> While I can sympathize with your problems fixing bad code left by other
> people, I am not sure how it is relevant on this list - is there
> something that people present on this list can help you with? What is it?

I think that this is the problem here. "fixing bad code" is simply not a 
statement that I recognise! I am not fixing bad code, I am re-writing much of it 
simply because the style is no longer acceptable, or somebody changed a default 
setting without considering the consequences ( <?= not working in PHP5.3 is 
STILL biting as ISP are only upgrading to PHP5.3! )

I still have not had a proper answer to a question I repeatedly ask. "Please can 
we have some tutorials on how 'strict' styling should be used?" I'm fixing the 
warnings created but I still do not fully understand what I am fixing. The main 
rework area has been not being able to use '$this' in static functions, even if 
the function checks $this and defaults to the static code internally. Adding 
'public/private/protected/static/self ...' and using them in the right places is 
well documented in bits and pieces, but there is no general 'how to' put the 
whole together? I suppose someone will want to add traits and the rest to that, 
but just a simple style guide for the basics would be nice ...
(Continue reading)

Permalink | Reply | 11 comments |
headers
Stas Malyshev | 1 Aug 2012 09:17
Favicon
Gravatar

Re: [PHP-DEV] Bringing users along ...

Hi!

> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that does not throw strict warnings from a stock 
> install of PHP5.4 as E_STRICT is on.

For PEAR is think it is a wrong list, as for PECL most extensions are
maintained by their maintainers, and internals specifically works only
on the core.

> I think that this is the problem here. "fixing bad code" is simply not a 
> statement that I recognise! I am not fixing bad code, I am re-writing much of it 
> simply because the style is no longer acceptable, or somebody changed a default 

You are trying to reframe the same meaning with different words, but the
meaning does not change - the code that is no longer acceptable in 5.4
is not acceptable for a reason. Usually the reason is that the code is
broken or using PHP in a wrong way - such as silently converting nulls
to objects, strings to arrays, arrays to strings, etc.

> setting without considering the consequences ( <?= not working in PHP5.3 is 
> STILL biting as ISP are only upgrading to PHP5.3! )

Err, I'm not sure what you mean - <?= certainly works in 5.3.

> I still have not had a proper answer to a question I repeatedly ask. "Please can 
> we have some tutorials on how 'strict' styling should be used?" I'm fixing the 
> warnings created but I still do not fully understand what I am fixing. The main 

I, for one, do not understand what you are asking. If somebody could
(Continue reading)

Permalink | Reply | 9 comments |
headers
Kris Craig | 1 Aug 2012 09:27
Picon
Gravatar

Re: [PHP-DEV] Bringing users along ...

On Tue, Jul 31, 2012 at 11:55 PM, Lester Caine <lester <at> lsces.co.uk> wrote:

> Stas Malyshev wrote:
>
>> Helping to solve the problem would also help everybody else upgrade TO
>>> PHP5.4?
>>>
>> OK, so what help do you require?
>>
> PEAR and PECL that work with PHP5.4 out of the box?
> At least the core of PEAR that does not throw strict warnings from a stock
> install of PHP5.4 as E_STRICT is on.
>
>
>  >Add to this the fun getting Apache 2.4 configured with PHP and my old
>>> framework,
>>> >it is no wonder I grumpy ... I would much rather be adding
>>> functionality and
>>> >working on NEW stuff than fixing the problems other people leave
>>> behind. And I
>>> >don't need any of the new PHP5.3/44 features to write my own new code.
>>>
>> While I can sympathize with your problems fixing bad code left by other
>> people, I am not sure how it is relevant on this list - is there
>> something that people present on this list can help you with? What is it?
>>
>
> I think that this is the problem here. "fixing bad code" is simply not a
> statement that I recognise! I am not fixing bad code, I am re-writing much
> of it simply because the style is no longer acceptable, or somebody changed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lester Caine | 1 Aug 2012 09:42
Picon
Favicon
Gravatar

Re: [PHP-DEV] Bringing users along ...

Stas Malyshev wrote:
>> setting without considering the consequences ( <?= not working in PHP5.3 is
>> STILL biting as ISP are only upgrading to PHP5.3! )
>
> Err, I'm not sure what you mean - <?= certainly works in 5.3.
Only with short tags on ... 5.4 has detached it from that, but 5.3 still 
switches it off by default, and convincing ISP to switch short tags on again is 
a lost cause :( Fixing it in PHP5.3 was rejected :(
Heck it took three days to get a reply that they had got a request about it, by 
which time everything was switched back to '<?php echo' ...
----

>> 'public/private/protected/static/self ...' and using them in the right places is
>> well documented in bits and pieces, but there is no general 'how to' put the
>> whole together? I suppose someone will want to add traits and the rest to that,
>
> How to put what together? The manual page for static states explicitly:
>
> Because static methods are callable without an instance of the object
> created, the pseudo-variable $this is not available inside the method
> declared as static.
>
> What other howto is needed for this?

Fine, so I just add 'static' rework all the code, and fix the error, but I think 
I should also be adding public as well? It's not needed to clear the warning, 
but should I also be going through every function and adding that, as well? 
Again, it's not a bug, but is all this extra syntax needed to get things into 
the right style for the next changes in PHP? You have to bear in mind than a lot 
of this code is ten years old and has been working fine all that time. I don't
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stas Malyshev | 1 Aug 2012 09:57
Favicon
Gravatar

Re: [PHP-DEV] Bringing users along ...

Hi!

> Only with short tags on ... 5.4 has detached it from that, but 5.3 still 
> switches it off by default, and convincing ISP to switch short tags on again is 
> a lost cause :( Fixing it in PHP5.3 was rejected :(

Errm... So you are complaining we're not going back in time now and make
different decision about PHP 5.3 that was made years ago? Or what is
your point exactly?

> Fine, so I just add 'static' rework all the code, and fix the error, but I think 
> I should also be adding public as well? It's not needed to clear the warning, 

If your functions are public, I'd recommend adding public. However, as
the same manual states, public is optional for BC reasons and if access
is omitted, public is assumed. Same manual, same page, one paragraph above:

For compatibility with PHP 4, if no visibility declaration is used, then
the property or method will be treated as if it was declared as public.

> mind so much some of the rework, but I've no confidence that I will not be doing 
> this exercise again next year - on the same code :(

If you want somebody to assure you that the code that nobody except you
have seen would not contain any problems after you fix some of the
problems you have now but nobody except you knows about - then I'm
afraid it's not something that anybody here is able to promise you. If
you have some specific proposal - let's hear it. Otherwise I'd recommend
following current best practices for writing good PHP code - e.g. what
described in the manual and many framework style guides, etc., don't use
(Continue reading)

Permalink | Reply | 7 comments |

Gmane