Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55947
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 81.20.134.149 cause and error)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <CAAyV7nEP=FLx7+=CnoV7HHDvmkD3pgOcjaHg1qvpGEp_Q6d_Gg@mail.gmail.com>
Date: Mon, 24 Oct 2011 21:29:12 -0700
Cc: Nathan Nobbe <quickshiftin@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <9ED08FED-A880-46DE-BF15-6CA56402DFF8@stefan-marr.de>
References: <CAL5nwZ6RF8Z3FV1vKgxoFZoBJiRp_qBNSx5MXAe_8-jbmj5OOA@mail.gmail.com> <CAAyV7nGK20r22e8TyquypLSn2irMHsoG6oK9vG7ge40WgYk1Ww@mail.gmail.com> <7403D757-228F-4C59-BCE5-8731BEC5CA25@stefan-marr.de> <CAAyV7nEP=FLx7+=CnoV7HHDvmkD3pgOcjaHg1qvpGEp_Q6d_Gg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Subject: Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
From: php@stefan-marr.de (Stefan Marr)

Hi Anthony:

On 24 Oct 2011, at 07:06, Anthony Ferrara wrote:

>> Please refer to: =
https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate
>>=20
>> "Traits do not provide any provisioning for handling state."
>=20
> The original RFC was correct in that traits should not have any state.
> However the implementation differs from the RFC significantly in that
> respect.

Please read the RFC. Thanks!

"Traits do not provide any provisioning for handling state."

"However, every behavior needs state to operate on, otherwise it could =
be just a static functional helper method. Thus, trait code will either =
need to use accessors, which is favorite way to go since it provides =
full traits semantics, or they use properties, which is possible but =
rather a convenience feature."

"Thus, the goal for a consistent language design is to raise awareness =
of the problem, promote the use of accessors, and break early in case =
the changes to a trait is potentially problematic for a class using it. =
This results in the following rules: [...]"

This is purely a matter of consistence with the dynamic nature of PHP.
We allow explicit naming of the properties, and that is all.

There is no handling of any semantics, there is no conflict resolution, =
there is no state merging, splitting or what ever you would need to have =
a powerful enough semantics for stateful traits.
Thus, I maintain the position that our traits do not provide any =
handling for state.
However, they break early when a conflict/incompatibility is assumed.
That is all, nothing more.

> Traits can explicitly define properties which actually
> prevent the parent class from changing this.
What is a parent class with regard to a trait? That concept does not =
exist.

>  See these two examples:
> http://codepad.viper-7.com/fqD91I and
> http://codepad.viper-7.com/DFDpqM
That is not a parent class, that is a using class or user, not a parent.

> So there is absolutely 100% support
> for state here.  I could understand if it was a dynamic property or
> the like, but this is really state.

As I outlined above, I disagree with that position. It does not mean =
that traits handle/have state!
That only means that we cater for the nature of PHP.

Perhaps the difference is academic, but it is quite important for me.
We cannot do without that breaking early property, because being =
conservative here seems the best option we have at the moment.
Bailing out in case of possible conflicts is the only way to avoid =
subtle bugs.

But the semantics of the properties are exactly as if they are defined =
in the class, which means that there is no notion of state what so ever =
associate with the trait. It is only realized in the final class, and =
the corresponding object.
The trait merely declares it.


>=20
>> The relevant part of the RFC: =
https://wiki.php.net/rfc/horizontalreuse#conflict_resolution
>>=20
>> We abandoned the idea of an explicit exclude operator long ago. (I =
think it was never in the PHP SVN.)
>> Thus, the situation you describe cannot occur in the sense that a =
method is missing from the class.
>> However, you can of course provide incompatible method =
implementations. (Which does not make traits any different from any =
other way to implement an interface.)
>=20
> The situation can absolutely happen simply with the conflict
> resolution (as you say).
I think, I do not understand what you are getting at.

The problem that cannot occur is that you get a runtime error because a =
method is completely missing from a class.
You can neither exclude nor rename a method. We do not have exclude, and =
we only got aliasing. Neither of these mechanisms will lead to a case =
where a method is completely missing from the eventual class.



> Implementation without any contract.

Yes.

Best regards
Stefan

--=20
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:   +32 2 629 3525