On Fri, Dec 10, 2010 at 12:55 PM, Matthew Weier O'Phinney < weierophin...@php.net> wrote:
> On 2010-12-10, Nathan Nobbe <quickshif...@gmail.com> wrote: > > --0016e6dbe7fb8861a1049712ad63 > > Content-Type: text/plain; charset=UTF-8 > > > > On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton <chadful...@gmail.com> > wrote: > > > > > On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe <quickshif...@gmail.com> > > > wrote: > > > > On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl <m4r...@gmail.com > > > > > wrote: > > > > > > > > > First i have to say that I am not a PHP internals developer, but as > a > > > user > > > > > I think it would maybe be better to just let the trait use the > > > implements > > > > > keyword, and "copy" that to the classes utilizing the trait? > > > > > > > > > > > > > This is actually in the RFC as a rejected proposal > > > > > > > > http://wiki.php.net/rfc/traits#rejected_features > > > > > > > > But what I'm talking about is something different. We're not trying > to > > > say > > > > 'these are the methods implemented in the trait', rather, 'this trait > > > > expects a class it is used with to be of a certain type or implement > a > > > > certain interface' for the trait to do its job. > > > > > > > > -nathan > > > > > > > > > > Shouldn't the burden be on the programmer to make sure the trait works > > > with the class using it rather than on the compiler? If they try to > > > use a trait that requires methods that don't exist, it will error out > > > anyway, so it won't be difficult to debug. > > > > Well I know PHP is a dynamic language but what about all the compile time > > features that have come along over the years. The abstract keyword for > > example vs. the PHP4 way of implementing an 'abstract' method which was > > triggering an error in the default implementation in a base class. > > > > One of the main things a lot of PHP programmers I've worked with hate is > > waiting for code to hit production and encountering a runtime error w/ > > something that could have been caught at compile time. I know the notion > of > > compile time in a scripting language like PHP is much less removed from > that > > of C++, Java etc, however there is a notion of it there, obviously. > > To me, putting this into the language feels like overkill. > > Unless you're using an opcode cache, the notion of compile time as a > differentiation from runtime in PHP has little relevance -- you still > only find out when the script executes. > *Only* if you hit the line of code at runtime that would destroy your script; often times this doesn't happen until it's too late, and the code has made it to production. And there is a notion of compile time in PHP, I'm not sure what it's referred to by the internals group, but abstract methods and interfaces definitely constitue compile time checks to me. > There's already a way to mitigate this as well: write a testing suite > for your application, and exercise it often. If you write your tests > well (targeting the discrete behaviors of your application), then most > likely they'll catch such errors -- allowing you to fix them before you > deploy. > Right, so you have to do tons of extra work (writing unit tests) which have to actually test every potential line of failure, when this could just simply be caught up front w/o any second guessing whether or not you've covered all cases in your tests. I'm not against unit tests at all, just saying it's much easier to guarantee you're safely using a trait w/ a compile time check rather than deferring the application author to test suite development. -nathan
