RE: [PHP-DEV] Extensions to traits

[Jonathan Bond-Caron]

On Sun Feb 13 05:15 AM, André Rømcke wrote:
 
  I have now made an RFC based on the most recent discussions:
 
  http://wiki.php.net/rfc/traitsmodifications
 
 
 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 cannot be re declared 
 without alias. Or better, add a new keyword since final should mean 
 final.
 

I find the implementation in trunk convenient, traits aren't meant to replace 
inheritance  ~polymorphism.

The 'final' keyword currently means nothing to the class:
trait Foo {
final static function test() {
return 'Test';
}
}

class A {
use Foo;
static function test() {
return 'Test2';
}
}

echo A::test(); // returns 'Test2' in trunk

That might seem odd but it's not inheritance.
There is no error if the class method signature is different from a trait.
I'm comfortable with 'the class always wins', not really sure if should I be 
thinking differently...

It makes a trait somewhat fragile but that's part of the design vs. grafts. 



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

RE: [PHP-DEV] Extensions to traits

[Jonathan Bond-Caron]

On Thu Feb 10 12:25 PM, Ben Schmidt wrote:
 
 http://wiki.php.net/rfc/traitsmodifications
 

Some thoughts:

a) Class method conflict with trait

Class implementation always wins I feel is the right way to think about
traits.

But 'abstract' already has special meaning, so maybe a keyword like 'final'
could also do something special.

b) Support for 'non-breakable traits'

 - Add trait-local scope

Really like the idea and how this could make traits less fragile. 
e.g.
trait Foo {
  trait $bar;   
  public $bar;
}

Could change the syntax to:
trait Foo {
  var $bar = 'visibleByTrait'; // variable private to the trait --
zend_mangle_property_name('#Foo {NULL} bar')
  public $bar = 'visibleByClass';  // variable public to the class it gets
composed in
}

class Test {
  use Foo;
}

$t = new Test;
echo $t-bar; // 'visibleByClass'

Seems like it could allow traits to have their own independent state
(private properties), internally ~ zend_mangle_property_name('#' trait name
{NULL} prop name).

Small note: is there a plan to drop the T_VAR token?

Any objections, concerns, more thoughts on the concept?

c)  Extend 'use' syntax

Didn't quite understand, will read again.
Have you thought about how this could affect the reflection api and
documentation?



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

[PHP-DEV] Heads-Up: 5.3.6RC Thursday

[Johannes Schlüter]

Hi,

a quick note: It's just a bit more than a month since 5.3.5 but as 5.3.5
didn't include most fixes done since 5.3.4 it's already time for 5.3.6.
Therefore 5.3.6RC1 will come on Thursday 17th, packaging Wed 16th evening
my time (Europe) Please make sure you don't break too much with last minute
commits. Please test the 5_3 branch. I hope for a quick RC cycle. 

Please note that there won't be VC6 builds on Windows anymore to reduce
maintenance work needed etc.

johannes


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