(I added internals back in to the Cc:; presumably you missed that out
by accident in your reply)
> Interfaces don't really provide this sort of functionality - take a look at
> c#,
> java or ruby to see
> better examples than mine of how attributes are used
Telling me to go and look at another language doesn't really answer my
question ;-)
It would be nice to see a concrete example of how it will benefit PHP.
> I suppose you can think of interfaces as providing a sort of binary-valued
> attribute system for classes,
> but they don't work for properties or methods.
It's just a different way of expressing your code; a pro-attributes
programmer is obviously not going to like coding with interfaces, and
perhaps vice-versa.
The counter argument to your last statement is that "they do if you
write your code the right way".
> The only way to do this currently is to implement some sort of properties()
> method on a class
> which returns e.g. a list of Property objects containing the name of the
> property each relates to, and a further list of
> that property's attributes. That's bad because the attributes then don't
> belong to the property.
>
>
> !-------- example (all sorts of problems with this, but you get the idea)
> ------------!
>
> class DBObject {
> public $dbid;
>
> function save() {
> $db = DB::handle();
> $values="";
> $comma="";
> foreach($this as $propname => $prop) {
> if($propname=="dbid") continue;
> $rp = new
> ReflectionProperty(get_class($this),$propname);
> if(!$rp->getAttributeValue("persist")) continue;
> $s = ($rp->getAttributeValue("serializer);
> if(!is_null($s) && method_exists($prop, $s)) {
> $val = $prop->$s();
> } else {
> $val = $prop;
> }
> $query.="$comma$propname='".addslashes($val)."'";
> $comma=",";
> }
>
> $db->query("UPDATE ".$this->tableName()." SET $values WHERE
> dbid=$this->dbid");
> }
> }
>
> class Person extends DBObject {
> [persist:true] public $firstName;
> [persist:true] public $lastName;
> }
>
> !------------- /example -----------!
>
> The implementation is to store the attributes as a string in the
> zend_property_info, so they would take little extra space.
It's not so much the storage requirements that I'm thinking of, as the
runtime accessing of that data. Looking at your example, the biggest
thing that strikes me is the amount of effort you need to go to, to
determine how to serialize the data.
So, again, I think serialization is not such a great example in the
context of PHP; there are faster ways to determine which properties to
serialize (returning an array of names is both simple and fast), and
nicer ways to actually serialize data: a set of well thought out
serialization interfaces are simple and clear to use. Serialization
is something that happens quite a lot in PHP applications, so it is
important to try and keep it fast.
I like the idea of attributes; I'm not against them making an
appearance in PHP, but you need to strongly convince the engine
developers that it's worth it. Arguments against things going into
the engine are usually performance related (both compile time and run
time) or php-spirit related (e.g: does it work in the "php way"?).
Another thing to consider is namespacing of attribute names. Maybe
one day we'll want to have attributes with special meaning to the
engine. Different frameworks will apply different meanings to the
same names. We tend to reserve names prefixed with underscores for
internal use; framework authors will need to appropriately namespace
their attribute names too.
Can you demonstrate some other practical use for attributes in PHP?
(please post an example to the list, even if it's psuedo-code--we're
mostly too busy to go off and read about something new until we've
been persuaded it's worth doing ;-)
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
