On 13/02/11 9:15 PM, André Rømcke wrote:
On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt
<mail_ben_schm...@yahoo.com.au>wrote:

On 11/02/11 3:37 AM, Philip Olson wrote:

You now have rights to the wiki rfc namespace.


Thanks a lot, Philip.

I have now made an RFC based on the most recent discussions:

http://wiki.php.net/rfc/traitsmodifications

I think this is a more solid proposal than my original one, and I hope
we can continue to discuss it and agree to the extent that it's worth
starting an implementation.

Please read it and comment whenever you can find some time, guys!



As for your first example:


trait T {
    public function foo() {
       echo<http://www.php.net/echo>  "T";
    }}class C {
    use T;
    public function foo() {
       echo<http://www.php.net/echo>  "C";
    }}


I think it would sometimes be desirable to allow this, for instance when a
trait has been updated in a framework to adapt to what has become common
practice in classes that uses it in the wild.
( I assume you already get error if function signature is different like in
inheritance? )

So to allow both cases, what about letting people use the final keyword on
functions to signal functions that can not be re declared without alias. Or
better, add a new keyword since final should mean final.

I don't mind that idea all that much, but perhaps doing the reverse
makes more sense: allowing a trait author to add a keyword to methods
which they intend and expect class authors to shadow. This means the
status quo is leaning towards stability, not breakages. Perhaps we could
reuse the 'default' keyword for this? That would indicate that the trait
has provided a default implementation of this method, but expects the
class author may well provide a more specialised implementation. Best
practice would then dictate that a responsible trait author should only
provide a default method for methods that were previously abstract
methods of the trait, so things wouldn't break, but traits can still
adapt to common practice, as you say.

So then this would generate an error, which could be resolved with an
insteadof in the use block:

trait T {
    public function foo() {
       echo "T";
    }
}
class C {
    use T;
    public function foo() {
       echo "C";
    }
}

But this would not:

trait T {
    default public function foo() {
       echo "T";
    }
}
class C {
    use T;
    public function foo() {
       echo "C";
    }
}

How does that sound?

Ben.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to