PHP has interfaces for this kind of thing, and they're clearer/cleaner
to use than the code you've posted (for this case at least).
It's also worth noting that the rendering of serialized data for an
object is usually better handled by the class of that object, not its
container. It is fine, of course, for the container to stick that
serialized data somewhere else.
Placing attributes in the container for this seems like a lot of extra
work; you'd be repeating the same mantra for each class that contains
and instance of the child class.
>From a technical viewpoint, how do these attributes affect the class?
Are they simply no-ops that are tagged and made available via the
reflection API? How does this really help improve PHP? I know it
sounds cool, but so does recording phpdoc comments, and we decided to
not do that in the default case for performance reasons. How are
these attributes much different from that?
I'm not against the idea per-se, I just can't see a really good reason
to justify it.
--Wez.
On 4/18/05, Duncan McIntyre <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am playing around with an extension to the Zend Engine 2 to allow class
> properties and methods to be tagged with attributes. These attributes would
> then be accessible through the Reflection classes:
>
> !---------- example -------------!
> class Storable {
>
> [serializer:toString; persistent:true; ] public $date;
>
> function __construct() {
> $this->date = new CDate();
> }
> ...
> ...
> }
>
> $store = new Storable();
>
> $rf = new ReflectionProperty("Storable","date");
> $s = $rf->getAttributeValue("serializer");
> if(!is_null($s) && method_exists($store, $s)) {
> $v = $store->date->$s();
> } else {
> $v = $store->date;
> }
>
> echo "the value of the date property is $v";
>
> !------------- /example -------------!
>
> I would find the ability to set attributes extremely useful in building
> frameworks a la Ruby On Rails.
>
> Anyone think this is a good idea?
>
> Duncan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
