On 2010-12-10, Nathan Nobbe <quickshif...@gmail.com> wrote: > --0016e6d7e101e083a4049714bad3 > Content-Type: text/plain; charset=UTF-8 > > 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.
That's what good testing is about -- exercising all the expected behaviors of your code. If you hit an unexpected behavior in production, you add a test to your suite that reproduces it, fix it, and re-deploy. > 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. Writing tests should not be considered "tons of extra work"; it should be considered a basic part of development. How can you prove your code does what it should without them? How can you insulate your code from future changes? As long as you consider it "extra work", I don't care what the compiler offers you -- you're going to shoot yourself in the foot some day. > 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. Again, are the benefits worth it, if you're writing code where an unexpected runtime exception could still occur because you didn't test properly in the first place? -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
