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 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.
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 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).
Yea, I completely agree.
I'm not against the idea per-se, I just can't see a really good reason
to justify it.
I hate to say this, but these ideas come from the "outside world":
- NUnit testing for .NET uses [Test] and [SetUp] attributes instead of
hardcoding method names (like test*, setUp, in xUnit test frameworks) - ASP.NET uses WebMethod attribute for automatically exposing XML Web Services
- Aspect#.NET uses attributes for aspect oriented programming stuff
Speaking of AOP, I wonder if AOP features will ever be possible in PHP
(I guess this deserves another thread, maybe I'll have to search
archives first...)
--
Hendy Irawan
http://www.gauldong.net
http://dev.gauldong.net
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?
A docblock parser would be nice though. :)
George
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?A docblock parser would be nice though. :)
And we have one as far as I know.
Derick
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:
Sorry guys to just jump in, but Duncan's idea is an EXCELLENT idea IMHO... :-)
Let's go beat up Ruby!!! ;-)
--
Hendy Irawan
http://www.gauldong.net
http://dev.gauldong.net
Hi,
[...]
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:
The PHP development team is usually against these kinds of OOP syntax sugar
additions, search Google / the archives for:
- Having IException as an interface instead of needing to
extend the builtin Exception class (php-internals) - Static initializers (pear-dev)
- with() keyword (???)
- Namespaces (php-internals, zendengine2)
- Operator overloading (php-internals)
- throws clause (zendengine2)
- Passing
NULL
to typehints (php-internals) - finally (php-internals)
- Return type hints (php-internals)
- self should reflect runtime class (php-internals)
- Automated getters/setters (php-internals)
(this list is by no means complete)
Having said that, how about implementing that in userland?
class Storable {
#[serializer:toString; persistent:true;]
public $date;
}
Extend (or wrap) the reflection classes and add:
MyClass::getAnnotations()
MyMethod::getAnnotations()
MyProperty::getAnnotations()
In those, parse the sourcecode with ext/tokenizer and extract all comments
beginning with the string "#[", push them into a hashmap and return it.
It's not as slow as you might expect. Of course, it'll only work if you
don't use "#[" in any other comments:)
- Timm
Timm Friebe wrote:
Extend (or wrap) the reflection classes and add:
MyClass::getAnnotations()
MyMethod::getAnnotations()
MyProperty::getAnnotations()In those, parse the sourcecode with ext/tokenizer and extract all
comments beginning with the string "#[", push them into a hashmap and
return it.
I would like to see a PEAR (or even PECL) package that provides this
functionality. I might even write it myself (given that I have a couple
of long train rides coming up I will probably do this anyhow :-)
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69