Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61925
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=utf-8
In-Reply-To: <6FD6848994B9428CBCDEDE22CEEF2E03@pc>
Date: Wed, 1 Aug 2012 17:02:10 +0200
Cc: <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9AFAC363-9B09-4752-9756-D903E8AF1264@stefan-marr.de>
References: <232501B15F7F4B3197123F219370E36D@pc> <A9048740-0311-4A3E-AF7A-77650F997790@stefan-marr.de> <2125641B4C7D4D6E8616F86C9C5563D2@pc> <5D98E000-D40D-43EC-9C94-D5B00331C82E@stefan-marr.de> <F35ED36746E94901A94CF4F6D2C4EB93@pc> <7D18CEE8-F045-43BF-BC4D-8A718FB5CED0@stefan-marr.de> <6FD6848994B9428CBCDEDE22CEEF2E03@pc>
To: Stan Vass <sv_forums@fmethod.com>
Subject: Re: [PHP-DEV] Traits behavior still up in the air in 5.4
From: php@stefan-marr.de (Stefan Marr)


On 01 Aug 2012, at 16:31, Stan Vass wrote:

>> Because it is not a matter of horizontal reuse.
>> Why don't you get a warning when you override an inherited method?
>> Because that is precisely the way things are supposed to work.
>>=20
>> The body of a class is not a trait. These methods are not 'equals'.
>> I still think that design decision is a sensible one with respect to =
the rest of PHP.
>=20
> If traits act like superclasses, why can the class call a private =
trait method, by that logic?

Traits have a very simple semantics:
Step 1: identify which traits are to be used.
Step 2: resolve conflicts between traits.
Step 3: flatten the result into the class.
Step 4: do in the class what ever you are used to do in a normal class.

This results in a "Glorified copy-and-paste.".
This explains why traits are allowed to access private methods, because =
they are part of the class. They are flattened into it.
But, they are flattened into the class before the body of the class is =
processed.


> So what is it? It's neither and both. I expect a mighty confusion and =
abuse of traits because they can't decide what they are in 5.4. Traits =
should pick one model and stick to it.

Yes, I agree with you that there are known problems with state.

To quote myself:=20
https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate


"Traits do not provide any provisioning for handling state. They are =
meant to provide a light-weight mechanism for flexible code reuse, with =
the main goal being to avoid code duplication."


Property support is a best-effort solution at the moment.

Following the rules outlined in the RFC:

"
	=E2=80=A2 Properties are considered incompatible if they differ =
in their definition. This means, they differ in the applied modifiers =
(static, public, protected, private) or their initial value.
	=E2=80=A2 Incompatible properties result in a fatal error.
	=E2=80=A2 In all other cases, i.e., when the definitions are =
identical, an E_STRICT notice is shown to raise awareness about the =
potentially problematic, and discouraged use of properties.
	=E2=80=A2 For those checks, all properties are treated equal. =
Properties from the base class and the composing class have to be =
compatible with properties from traits as well as the properties between =
all traits have to be compatible.
	=E2=80=A2 Non-coliding properties, and properties which are not =
considered incompatible behave exactly the same as if they would have =
been defined in the composing class.
"

Please provide a fix in form of an RFC and a patch.
Thank you!



> My proposal is what I said above. Either aliases should be *dropped* =
as a feature from traits and the feature has to be rethought, or they =
have to work sensibly as outlined in 1) and 2) above.
>=20
> IMO they do more harm than help in their current form. Sometimes not =
implementing a compromise is a feature itself.

I disagree with the premise that renaming is necessary.


>> http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf
>=20
> Let me quote that PDF you've linked me to:
>=20
> "By default, variables are private to the trait that de=EF=AC=81nes =
them. Because variables are private, CONFLICTS BETWEEN VARIABLES CANNOT =
OCCUR when traits are composed. If, for example, traits T1 and T2 each =
de=EF=AC=81ne a variable x, then the composition of T1 + T2 does not =
yield a variable con=EF=AC=82ict. Variables are only visible to the =
trait that de=EF=AC=81nes them"
>=20
> "By default, instance variables are private to their trait. If the =
scope of variables is not broadened at composition time using the =
variable access operator, CONFLICTS DO NOT OCCUR AND THE TRAITS DO NOT =
SHARE STATE."
>=20
> Emphasis mine.
>=20
> This is absolutely not what is implemented in 5.4, and this is in part =
why we're having this thread now.

You are missing the point of the complexity that comes with the whole =
proposal.
Granting access, and merging add quite some complexity to the language =
(not only the implementation).
There have been proposal like a 'local' keyword for traits before.
They never got implemented.


> My point which I've described multiple times at this point is that =
traits are not classes, we already have classes in PHP, you know? =
Imitiating classes with traits is the wrong mental model for their =
behavior, and the paper you're linking me to confirms tht.

How do you prevent a user from using dynamic (properties that are not =
predeclared) in a method that comes from a trait?



>> There is nothing simple in PHP...
>> People don't like fatal errors, especially not for things they intend =
to just work.
>> =46rom my example above, the kind of guarantees you expect are just =
not something that is part of what PHP is.
>=20
> Letting conflicts overwrite randomly properties is not "just working". =
It's an example of "not working, and it's very hard to debug why."

Again, what is your point? PHP is the wrong language for you then.
PHP is very dynamic and let's you shoot yourself in foot in all kind of =
strange ways.

Traits do not change these semantics. They try to integrate with them.
And the main problem here is that PHP got dynamic properties.

If you want to change the semantics to 'local-to-trait'-by-default =
fields, please provide a patch and an RFC. I won't stop you. On the =
contrary, it is certainly an appealing option.

Throwing a FATAL however is not an appealing option.
We are already pretty strict when we see that it is most likely a bug.
And we give you a E_STRICT warning. That's what we can do for the =
moment.

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