Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51008
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.45 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=VndcGag0Y6oz+60ZZ9kFWOh0f2uw+m4w/1Lo+T+TeuHKA07X25hcQbG6NTIhKIpFec
         AEq588ntlPM/kKFTATzVu/kmcDxtt1KlErV4NGzAeUQT3hvMCVjYoDKTLHxdK6lx56IB
         Kl8/DEJLhf8UvJBkmv2OrJnBbPRIaaRsveR98=
MIME-Version: 1.0
In-Reply-To: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
Date: Sat, 11 Dec 2010 11:35:01 -0700
Message-ID: <AANLkTimUdjA6pAVMN1V7Nr2En46AO_82iit1XfAXgtVY@mail.gmail.com>
To: Stefan Marr <php@stefan-marr.de>
Cc: "internals@lists.php.net Development" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636c5a5eb8aba7c049726ba5b
Subject: Re: [PHP-DEV] Traits and Properties
From: quickshiftin@gmail.com (Nathan Nobbe)

--001636c5a5eb8aba7c049726ba5b
Content-Type: text/plain; charset=UTF-8

On Sat, Dec 11, 2010 at 9:47 AM, Stefan Marr <php@stefan-marr.de> wrote:

> Hi:
>
> Traits do not provide any special provisioning for handling properties,
> especially, there is no language solution for handling colliding property
> names.
> 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 reference
> to the property in the class.
>
> However, at the moment it is possible to define properties in a trait:
>
> trait Foo {
>  private $a;
>  public  $foo;
> }
>
> For the moment, that information is completely ignored, thus:
>
> class Bar {
>  use Foo;
> }
> property_exists('Bar', 'a') === 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
> altogether.
> That reduces a bit the possibility to have wrong expectations about
> properties, 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 merge
> 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
> whenever properties are silently merged.
>

I would prefer they be definable within traits and merged into classes,
otherwise traits will not have the chance to be self-contained entities of
reusable logic.  Also, I think merging them in is consistent with the
treatment given to methods as they pertain to traits.

As I'm sure you know:
<?php
class A {
  use SomeTrait;
}

trait SomeTrait {
  public function traitMethod() {}
}

method_exists('A', 'traitMethod') === true;
?>

Regarding visibility modifiers, why not carry them over from the trait
directly, private in the trait definition results in private in the class
definition.  Lastly, I'm not sure why you would want to discourage this
usage, I would plan on adding properties in traits myself.

-nathan

--001636c5a5eb8aba7c049726ba5b--