Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51010
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:content-transfer-encoding;
        b=jgOcaiqzox/PeAtph70noGk3drba3inZ83LMSDT0OWHElenqCFLIJYlXvHzu7N+q9d
         reNFPoiQbjc4G5iwkzxCplqxTGmWzZe0mvtscz4rnj47bHbFVeLMGg13PdvXEfRQcrd2
         gDB+BaXtiZIk2a2uJ+FoEJmHv7KUHxDb7px0w=
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 23:13:12 +0100
Message-ID: <AANLkTi=XzoOPi17KnKPhqy7xaiJHcRjmM40WV1FO5A39@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=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Traits and Properties
From: pierre.php@gmail.com (Pierre Joye)

hi,

Would it be possible to somehow document what you are discussing here?
It is not too easy to keep track of all discussions about traits
(along other things). Maybe in draft RFC or a simple page in the wiki.
Doing so will help to have a quick view about the open questions or
recent changes/propositions.

Thanks!

On Sat, Dec 11, 2010 at 5:47 PM, 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 {
> =A0private $a;
> =A0public =A0$foo;
> }
>
> For the moment, that information is completely ignored, thus:
>
> class Bar {
> =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
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax: =A0 +32 2 629 3525
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org