On Thu, Jun 27, 2013 at 10:50 AM, Florin Patan <florinpa...@gmail.com>wrote:
> On Wed, Jun 26, 2013 at 5:02 PM, Anthony Ferrara <ircmax...@gmail.com>
> wrote:
> > Florin
> >
> >> Could you please point out what happened in the past 5 months in PHP
> >> that changed the landscape so drastically as you say? And don't
> >> mention folks reinventing the wheel in OOP because that's not news :)
> >
> >
> > The point was that "best practice" is volatile and temporal, and changes
> > depending on who you talk to. Therefore, it becomes a very poor criteria
> to
> > judge a language change by...
> >
> >>
> >> And could you also please answer this question: what happens when this
> >> code:
> >>
> >> // Third party Mighty Logger Library
> >> interface Logger {
> >> public function log($argument);
> >> }
> >>
> >> // My beloved implementation
> >> class Demo {
> >> public function log($argument) {}
> >> }
> >>
> >> class UseMe {
> >> public function shazam(<Logger> $logger) {
> >> $logger->log('shazam');
> >> }
> >> }
> >>
> >> $demo = new Demo();
> >> $useMe = new UseMe();
> >>
> >> $useMe->shazam($demo);
> >>
> >> becomes
> >>
> >> // Third party Mighty Logger Library
> >> interface Logger {
> >> public function log($argument);
> >> public function unlog($argument);
> >> }
> >>
> >> // My beloved implementation
> >> class Demo {
> >> public function log($argument) {}
> >> }
> >>
> >> class UseMe {
> >> public function shazam(<Logger> $logger) {
> >> $logger->log('shazam');
> >> }
> >>
> >> // New method written by different enthusiastic programmer
> >> public function kazam(<Logger> $logger) {
> >> $logger->unlog('kazam');
> >> }
> >> }
> >>
> >> $demo = new Demo();
> >> $useMe = new UseMe();
> >>
> >> $useMe->shazam($demo);
> >> $useMe->kazam($demo);
> >>
> >>
> >> How would IDE be able to provide any useful information in this case,
> >> like they do now with type hints?
> >
> >
> > The IDE would behave identically as it does now. The only way that the
> IDE
> > could provide you meaningful information today would be to track the
> `$demo`
> > variable from creation to being passed to those two methods. If the IDE
> can
> > track that and give you an error today, it can still give you the same
> error
> > tomorrow. Sure, if you implement the logger interface on Demo it can find
> > the error, and there's nothing stopping you from doing that. The key is
> that
> > it's not *required*...
>
> Yeah, but you just made me to implement the interface in my class
> which I don't want do, because of this feature.
> And more often that not, I'm using third party libraries which will
> have deeper implications.
>
> > And the key here is to realize that this feature is designed to decouple.
> > And that comes at a cost (reducing the ability for static analysis). But
> you
> > gain a very significant amount of flexility by it. And that's worth it
> IMHO.
> > If you don't program that way, I completely understand. But it is a valid
> > approach that's currently being used.
>
> Again, can you explain what is this decoupling you are talking about?
> Sorry, I'm a bit confused. The fact that you have a interface from
> another package in your implementation? And you depend on having that
> package as well in your code? Or the fact that once you've written
> implements PSR3LoggerInterface you'll have to implement all those
> additional methods? (see below for the continuation)
>
> >>
> >> Yes, it's a nice academic feature, but if I'm doing a code review,
> >> when I see that a class implements a certain interface or a parameter
> >> has a certain type-hint then I can be sure that I won't need to review
> >> the interface and the implementation to match all the possible methods
> >> in that class and if I'm using a third party app review that as well
> >> to make sure that the guy who's using this 'weak type-hinting' aka
> >> protocol type hinting as you call it won't mess up.
> >
> >
> > In theory this sounds like a great argument. In practice, I don't think
> it
> > holds up. The main reason is that look at other languages. Look at Perl.
> > Look at JavaScript Look at Python. Look at Ruby. Look at Go. Look at C.
> Look
> > at C++. None of them have the contract based typing that PHP does. But
> all
> > of them get by just fine. And 2 of them use structural typing like this
> (Go
> > and C++).
>
> But they are not PHP programmers :) Granted you will still have the
> average Joe or intern Joey in there as well but C. C++ and GO are
> compiled, last time I've checked. And don't even try to say that, the
> bundle off mess which even its creators regret doing it like that,
> Javascript is OO :)
>
> I think this only mattered if there was some sort of maybe performance
reason not to do it which i think Anthony has successfully to this point
proven there isn't. We use tons... no really we basically stole everything
from other languages.
> See the point above...
> >
> >>
> >> Can you please address these issues?
> >
> >
> > Other than pointing out that these issues don't really exist in general
> > (they are just a perspective based on an approach, rather than inherent
> to
> > the concept), I'm not sure how... You have a different approach to code
> than
> > I do. That doesn't mean either of us is wrong. It just means we value
> > different things. And that's ok...
> >
> > Anthony
>
> Seriously? (for measuring contest) lease look at my LinkedIn profile,
> I'm working with PHP for 7 years or so in various companies of
> different sizes, clients, domains and most of all, I'm using stuff
> that you can find in PEAR/packagist and phpclasses.
>
Maybe I wasn't clear. PLEASE STOP THIS! We're a freaking open source
community. Measure this on merit.
> Best regards
> ----
> Florin Patan
> https://github.com/dlsniper
> http://www.linkedin.com/in/florinpatan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
