Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51018
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type:content-transfer-encoding;
        b=tYTTsgC9W/UHNxmHdqLNIKV8SGlPtHQBgysW8AA0OaOMwHcd36GQdJfeSOBGX2VBmY
         zWnoNv4VeyO6LRrXS5CzsNGs4f7a27OqwlX/n5NH39ccm3GAOEv1KGrqpyxmIZrY/B+O
         7cqJ8MKj7ICW7keRspvE/6JLKDBhFg4bhd4AQ=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
Date: Mon, 13 Dec 2010 13:13:22 +0000
Message-ID: <AANLkTi=dz1pu7B+1k-xAbCRPmFx24J=27ABaWLRuPwqK@mail.gmail.com>
To: Stefan Marr <php@stefan-marr.de>
Cc: "internals@lists.php.net Development" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Traits and Properties
From: rquadling@gmail.com (Richard Quadling)

On 11 December 2010 16:47, Stefan Marr <php@stefan-marr.de> wrote:
> Hi:
>
> Traits do not provide any special provisioning for handling properties, e=
specially, there is no language solution for handling colliding property na=
mes.
> The current solution/idiom for handling state safely in a trait is to use=
 either abstract set/get methods or an abstract get that returns a referenc=
e to the property in the class.
>
> However, at the moment it is possible to define properties in a trait:
>
> trait Foo {
> =C2=A0private $a;
> =C2=A0public =C2=A0$foo;
> }
>
> For the moment, that information is completely ignored, thus:
>
> class Bar {
> =C2=A0use Foo;
> }
> property_exists('Bar', 'a') =3D=3D=3D false
>
>
> Well, and that is a rather inconsistent status-quo.
>
> I would like to have that fixed in one or another way.
>
> One possibility would be to forbid property definition in a trait altoget=
her.
> That reduces a bit the possibility to have wrong expectations about prope=
rties, however, the dynamic property creation is still possible.
>
> Another way would be to merge the properties in the composing class.
> The question here would be how to treat visibility modifiers: how to merg=
e public and private, should it result in public, or private?
> And, to discorage users to go this way, should there be a STRICT notice? =
Options here are a notice whenever a property is defined in a trait, or whe=
never properties are silently merged.
>
>
> Comments very welcome.
>
> Thanks
> Stefan

From the rfc [1], "A Trait is similar to a class, but only intended to
group functionality".

I'm guessing that says it all. A trait has no properties.

But.

If properties are to be added to a trait, I think that should come as
a further enhancement and let traits start out as "methods only".

If a trait is properties, then also supporting constants and the other
sort of set/get properties would provide a strong level of
consistency. If I can put it in a class, I can put it in a trait.

As visibility on the traits methods can be manipulated via the
aliasing mechanism, so should any visibility to a property.

Richard.

[1] http://wiki.php.net/rfc/horizontalreuse
--=20
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY