Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67965
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAA9esySu6QWgQ7OOK0RdZLV6c=KfWyfC5c8Hv4HDzGBZJzYSVw@mail.gmail.com>
References: <CAAyV7nGo4+n_4Ad7oKyuvLWTtmnui7fn6s-noCwG2PtT5A70tQ@mail.gmail.com>
	<51C9FA9C.8050403@sugarcrm.com>
	<CAAyV7nHz0E2Tmin5_S4OVii=U1HhuKKL6y_KAa+j=X7DT9My6g@mail.gmail.com>
	<51CA1C93.6080500@sugarcrm.com>
	<CAAyV7nHo-ZLx2F=+6URctZXTqx8tLgR=xG7j0wJ3unmiCxGvXQ@mail.gmail.com>
	<51CA24C5.9090505@sugarcrm.com>
	<CAAyV7nG2Lmo0q01KGbKpBzpJXbs-2E+1ir8yCOFnN8yC-Up2Gw@mail.gmail.com>
	<CAA9esyTYaHQ_wHo9njndLekNmbsrggUQvHaHEZbQxAU=nAaoFA@mail.gmail.com>
	<CAAyV7nG-RK+BSq8N1cWGFT74BOZXHnbnHVie6btpNkVxXzgXcg@mail.gmail.com>
	<CAA9esySu6QWgQ7OOK0RdZLV6c=KfWyfC5c8Hv4HDzGBZJzYSVw@mail.gmail.com>
Date: Thu, 27 Jun 2013 10:57:08 -0500
Message-ID: <CAO3MkaC32FMjw=M5TqF-Z6QYdN2F_Mvw9hfdh5ubM4vy_=Djhg@mail.gmail.com>
To: Florin Patan <florinpatan@gmail.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f3ba52589e6cd04e024d0a9
Subject: Re: [PHP-DEV] RFC: Protocol Type Hinting
From: neclimdul@gmail.com (James Gilliland)

--e89a8f3ba52589e6cd04e024d0a9
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 27, 2013 at 10:50 AM, Florin Patan <florinpatan@gmail.com>wrote:

> On Wed, Jun 26, 2013 at 5:02 PM, Anthony Ferrara <ircmaxell@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
>
>

--e89a8f3ba52589e6cd04e024d0a9--