Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.46 as permitted sender)
MIME-Version: 1.0
Sender: mikegstowe@gmail.com
In-Reply-To: <CAKUjMCWWmhkQTMLoof76nFZEZs80cz4KFgKtw5UzsX6XwFMoVw@mail.gmail.com>
References: <4E29949C.9020209@gmail.com> <CAKUjMCWWmhkQTMLoof76nFZEZs80cz4KFgKtw5UzsX6XwFMoVw@mail.gmail.com>
Date: Fri, 22 Jul 2011 11:12:07 -0500
Message-ID: <CAH8KiX+HKLU_eW2ZCKkNi_TQi2M0GxXm+fa5Sr+8HEfwjg6mPw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=000e0ce0ee564c739d04a8aabb99
Subject: Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
From: me@mikestowe.com (Michael Stowe)

--000e0ce0ee564c739d04a8aabb99
Content-Type: text/plain; charset=ISO-8859-1

Didn't send to list the first time, please accept my apologies if you
received this twice  - Thanks

That makes sense if it would overwrite the methods as well, but otherwise it
seems like it provides inconsistent functionality.  Perhaps I'm wrong as
likewise I have a very limited understanding here.

- Mike



-- Past Conversation ---
---------------------------------
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.

Richard

---------------------------------

I was under the impression that traits were not supposed to have
properties at all:

From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a common
practice to give this requirements explicitly. This is possible with
abstract methods like it is used for abstract classes.

Is the support for properties the bug perhaps?

Anthony


---------------------------------


Hello folks,

I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.

Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:

trait foo
{
    public $zoo = 'foo::zoo';
    public function bar()
    {
        echo "in foo::bar\n";
    }
}

class baz
{
    use foo;
    public $zoo = 'baz::zoo';
    public function bar()
    {
        echo "in baz::bar\n";
    }
}

$obj = new baz();
$obj->bar();
echo $obj->zoo, "\n";

We get:

in baz::bar
foo::zoo

It seems this is not correct and that it should be:

in baz::bar
baz::zoo

The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?

Alex

--000e0ce0ee564c739d04a8aabb99--