$args = array_merge( array( $object ), $args );

in the callmethod()

if the trait methods require access to the calling object, it is better to pass it in during construction e.g.;

/**
* Add extended details trait
* Provides:
* $this->getExtended()
* $this->addExtended(array $details)
* $this->updateExtended(array $details)
*/
function _initTraits() {
parent::_initTraits();
$this->_registerTrait( new Trait_ZWIdentExtended(array(‘model’=>$this)));
}

This removes an element of dependency if it isn’t required.

Cheers

>> A ‘Trait’ is what we call a Mixin.
Who/what is we?

As I understand it, Mixins are more complex than traits and carry some of the same problems as mulitple inheritance. At least as far as PHP goes, the terminology is all a bit vague until something actually gets implemented.

>> But I dislike the usage of __call for the trait-methods because a Reflection cant list them. This prevent “code completion” and “class browsers”)
Agreed – this approach does have some drawbacks. That said, so do the alternatives.

If you use a code generation technique as suggested by Ralf, you’re still duplicating code and need to re-run the code generation whenever one of the traits/plugins/mixins is modified. The only way we’re likely to see a completely “clean” implementation is if/when some form of horizontal code re-use becomes a feature of PHP.

>> I also would say it is not necessary to make the access to $_traitBroker private. Because you provide access to the whole Object via getTraitBroker.
A tiny implementation detail, but yes, you’re right.

>> So you can make a cleaner Interface with lesser code and no ‘magic’
How? Perhaps I’m missing something, but I don’t see what your suggestion is?

But I dislike the usage of __call for the trait-methods because a Reflection cant list them. This prevent “code completion” and “class browsers”)

I also would say it is not necessary to make the access to $_traitBroker private. Because you provide access to the whole Object via getTraitBroker.

So you can make a cleaner Interface with lesser code and no ‘magic’

I like your reflection/code generation approach and the “compatibility” with code assist is a big plus. Sadly, one downside of complex OO approaches is that most IDEs just can’t handle them!

I haven’t played around with Zend_CodeGenerator yet but it looks like an interesting component.

Thanks again for the comment.

Interesting indeed. It seems like a generic object plug-in system. Sure, this fits OOPLs other then PHP as well.

I recently sketched out a solution witch uses code generation for mixing-in other classes functionality. While this approach does not make massive use of PHP’s magic method mechanics, it enables the developer to have code assist from an IDE. But this is only kind of a side effect. The post is really about generating type-checking property accessors.

Have a look: http://blog.uebercode.org/2010/03/static-annotation-driven-php-code.html

I would appreciate some comments on this

Regards!

Aaron