Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15997
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Organization: Calligram Ltd
To: internals@lists.php.net
Date: Mon, 18 Apr 2005 15:57:24 +0100
User-Agent: KMail/1.7.1
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200504181557.24846.duncan@calligram.co.uk>
Subject: Re: [PHP-DEV] Attributes support proposal
From: duncan@calligram.co.uk (Duncan McIntyre)

>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).

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.
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.

Doing this with docblocks would be *horribly* inefficient. I know historically we've used docblocks in php to add
metadata to things, but that came about because we didn't have a visibility mechanism or type hints on parameters. 
And anyway we don't store docblocks for properties.

[Aside] 
In the present engine method docblocks are stored, but this is not really necessary since the line and file the 
method is defined in is also stored and could be used to pull the comments from the source on-the fly.
A look-aside caching mechanism could be used to export these for encoded files.
[/Aside]

I agree that my example is not the best example of how attributes can be used, it was more to show syntax. 
That said it would make the job of automating object-relational type code much easier. Example below. 
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.

The implementation in the Zend engine is to store the attributes as a string in the zend_property_info, so they would take little extra space.

!-------- 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("serialize);
                        if(!is_null($s)) {
                                $val = $prop->toString();
                        } 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; // string value
        [persist:true] public $lastName; // string value
	[persist:true; serialize:true] public $dateOfBirth; // CDate

	function __construct() {
		$this->dateOfBirth = new CDate();
	}
}



!------------- /example -----------!

-- 
-----------------------------------------------------------------

Duncan McIntyre
Director
Calligram Ltd
71 Madeley Road
Ealing, London W5 2LT

duncan@calligram.co.uk
(+44) 208 997 6241 - Office
(+44) 7919 050 239 - Mobile