Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=fOemoQAI+/PlZ6RV2ewgt3xpXgc2aEcA+HYnynJvoWoiOhGoAP+42O1oUhbuDJ0CMb
         kRTQJb6AJydgkR9+eDMXE8QMSJlCQoWh4NibPrN7pYkN6L4LP6fJo5MJ+JGDb7ZlR0w/
         dyj52A96Ve/69q8a7swFC1KhUL8tjYJdtoiys=
MIME-Version: 1.0
In-Reply-To: <9A31F2F9-ED6B-4BE5-A6E2-EB4536E8667F@stefan-marr.de>
References: <AANLkTim9wJSM9XrZu7JHmvX04ZfE+Bikz_-SP+6aJx79@mail.gmail.com>
	<9CD87200-33CB-40BE-A81C-36FD7471F59C@stefan-marr.de>
	<AANLkTinEUskDW=wncdQz+p4awnXt+n+FRHwUVsH1E0ac@mail.gmail.com>
	<9A31F2F9-ED6B-4BE5-A6E2-EB4536E8667F@stefan-marr.de>
Date: Fri, 10 Dec 2010 09:18:52 +0300
Message-ID: <AANLkTi=OThaENKviKwa6mRcOdK71aNzNQwSi8L=R26eL@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016363104511082bb04970854c7
Subject: Re: [PHP-DEV] Traits expecting interfaces implicitly leads to
 expensive runtime checks
From: crocodile2u@gmail.com (Victor Bolshov)

--0016363104511082bb04970854c7
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

Personally, I believed that traits are a *compile time injection* to a
class, so that at runtime a class behaves completely as it would if trait
methods were implemented directly in the class. That said, everything like
trait requirements for a certain interface, should be done at compile time
and constructions like abstract foo(); in a trait serve that purpose. IMHO.

2010/12/10 Stefan Marr <php@stefan-marr.de>

> Hi Nathan:
>
>
> On 09 Dec 2010, at 23:42, Nathan Nobbe wrote:
> > What I'm getting at is the scenario when a trait is designed to be used
> in
> > concert with the class in which it is being used.  In this case the tra=
it
> > expects certain functions to be available on the class in which it is
> used
> > with.  If the methods aren't there (or checked for at runtime) a fatal
> error
> > is raised.
> >
> > A quick example
> > <?php
> > class A {
> >  use AHelper;
> >
> >  function blah() {}
> > }
> >
> > trait AHelper {
> >  function meh() {
> >    // hoping we get used w/ instances of A ...
> >    return $this->blah() * 5;
> >  }
> > }
> >
> > class B {
> >  use AHelper;
> >
> >  /// waiting for a runtime error if blah() is ever called ..
> > }
> > ?>
> >
> > Do you see what I mean?
> No, do not really see what you are getting at.
>
> How is your approach using the instanceof checks (from the first mail)
> different from changing AHelper to require blah() by stating this
> requirement using an abstract method definition?
> For the trait it is not important where that method is implemented, it ju=
st
> has to be in the final composed class.
>
> So, why don't you want the following trait?
>
> trait AHelper {
>  abstract function blah();
>
>  function meh() {
>   // hoping we get used w/ instances of A ...
>   return $this->blah() * 5;
>  }
>
> }
>
> You want to avoid the fatal error during runtime, right?
>
> Do you prefer dynamic checks over compile time checks?
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD,
=F7=C9=CB=D4=CF=D2

--0016363104511082bb04970854c7--