Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92649
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAFKaYMqg6H2YAgS-ATjcYtXw8GLbp_Kr+VuZFMRPZTkAS1g0hA@mail.gmail.com>
 <571965D1.9020102@zend.com>
 <CAFp73Xs=-sK4ZM-mM8Jp5wWkpYLuen+-K0R9xfZaumBM_sPPFw@mail.gmail.com>
 <5719CDB2.90103@zend.com>
 <CAFp73XtqBtLdoTykrg_1eeJZTFszcmutNpynmyGKEizPiC2Juw@mail.gmail.com>
Message-ID: <571A499D.4090200@garfieldtech.com>
Date: Fri, 22 Apr 2016 10:56:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAFp73XtqBtLdoTykrg_1eeJZTFszcmutNpynmyGKEizPiC2Juw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: larry@garfieldtech.com (Larry Garfield)

On 4/22/16 10:39 AM, guilhermeblanco@gmail.com wrote:
> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>
>>
>> 3- Did you put any thought on inheritance? What I mentioned in comment #1
>> is even smaller than what you implemented in RFC.
>> Assuming you keep the RFC approach, did you consider support overrides,
>> inherit, etc?
>>
>>
>> In my opinion, attributes don't have to be inherited.
>> If you think differently - please explain your point.
>>
> Of source I can.
> A simple case would be to increate visibility of the inherited property. It
> was declared in a parent class as protected, but now you want public, and
> you still want to keep all parent defined Attributes.
> Another example is like we do in Doctrine. We support a callback system
> which we named as lifetime callbacks. Pre-persist is one of them, which is
> called every time a given Entity is about to be persisted into DB. When
> you're dealing with inheritance, you can potentially override the method
> content and you still want to trigger the same operation as if it was
> untouched. Example:
>
> use Doctrine\ORM;
>
> trait Timestampable {
>      protected $created;
>      protected $updated;
>
>      <<ORM\PrePersist>>
>      public function prePersist() {
>          $this->created = $this->updated = new \DateTime("now");
>      }
>
>      <<ORM\PreUpdate>>
>      public function preUpdate() {
>          $this->updated = new \DateTime("now");
>      }
> }
>
> <<ORM\Entity>>
> class User {
>      use Timestampable;
>
>      public function prePersist() {
>          // Add my custom logic
>      }
> }
>
> The implication is that through a simplistic approach, inheriting (or
> overriding) is not clear and I can't figure it out an easy way to achieve
> that.
> Now if we go towards calling a function or class constructor like I
> mentioned before, then we could easily build structures like __Inherit,
> __Override, etc.
>

Here's another example from a Doctrine-using project I built a while 
back.  (Not the exact code, but the same concept; I've adapted it to PHP 
7 types as well):

interface Ownable {
   public function getOwner() : string;
   public function setOwner(string $u);
   public function isUnowned() : bool;
}

trait OwnableTrait {

   /** @ORM\String **/
   private $owner = '';

   public getOwner() : string {
     return $this->owner;
   }

   public setOwner(string $u) {
     $this->owner = $owner;
   }

   public function isUnowned() : bool {
     return $this->owner == '';
   }
}

/** @ORM\Entity */
class Product implements Ownable {
   use OwnableTrait;

   // ...
}

class Widget extends Product {
     // ...
}

For annotations to work for this use case, reflecting on the properties 
of Widget would need to include $owner, and it would need to include the 
ORM\String annotation.  (True regardless of whether annotations are 
array or object based.)

-- 
--Larry Garfield