Bug #62537 [Ver]: Composed class has fatal error with duplicate, equal array properties

From: Date: Tue, 07 Feb 2017 23:45:10 +0000
Subject: Bug #62537 [Ver]: Composed class has fatal error with duplicate, equal array properties
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-207220@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=62537&edit=1

 ID:                 62537
 Updated by:         requinix@php.net
 Reported by:        jeremeamia at gmail dot com
 Summary:            Composed class has fatal error with duplicate, equal
                     array properties
 Status:             Verified
 Type:               Bug
 Package:            Class/Object related
-Operating System:   Ubuntu
+Operating System:   *
-PHP Version:        5.4.4
+PHP Version:        Irrelevant
 Block user comment: N
 Private report:     N

 New Comment:

The documentation is indeed out of date.

No E_STRICT in PHP 7:
- https://3v4l.org/Jafoi matching in two traits
- https://3v4l.org/pQYTl matching in traits and class

Conflicting definitions:
- https://3v4l.org/brZt0 conflict between traits
- https://3v4l.org/umfVE conflict between trait and class


Previous Comments:
------------------------------------------------------------------------
[2017-02-07 23:09:12] mail at pmmaga dot net

In PHP7.0, this E_STRICT was dropped as described in the 7.0 docs: http://php.net/manual/en/migration70.incompatible.php

> Same (compatible) property in two used traits	- Notice removed, triggers no error

However, the documentation on traits still mentions the E_STRICT.

------------------------------------------------------------------------
[2013-09-19 09:10:51] gron@php.net

I believe this is going to be problematic, because the object/array is not the 
same, i.e., it is not the same literal, and I assume that I currently check for 
object identity. Object identity works for most literals, but not arrays.

To fix this, special care is required. A value comparison might be possible, and 
would be necessary here. A simple check for the type is not sufficient, because 
$var = 1; vs $var = 2; should result in the expected error.

But yes, in general, I consider this behavior a bug.

------------------------------------------------------------------------
[2013-09-15 01:27:48] metamarkers at gmail dot com

This is a bug. It should not a be a fatal error if the initial value is even the 
same **type**. Consider using traits to define default static vars. Defining them 
through inheritance, these static vars are clobbered unless explicitly redefined 
in every child class.

It makes perfect sense not to allow this with constants, but why static 
variables?

------------------------------------------------------------------------
[2012-10-26 19:09:49] dagguh at gmail dot com

If it is logically the same thing, it should be only in one of these traits, don't 
you think?
SRP and DRY, fellas

------------------------------------------------------------------------
[2012-07-20 09:07:13] aharvey@php.net

I'd call this a bug, rather than a documentation issue; if Foo::$var === Bar::$var, I
can't really see why it should fatal.

Reclassifying, and we'll see what the engine folk think.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=62537


--
Edit this bug report at https://bugs.php.net/bug.php?id=62537&edit=1


Thread (1 message)

  • requinix@php.net
  • Unknown Message
    • requinix@php.net
« previous php.bugs (#207220) next »