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 :)
If you would work in a real world company, which I suspect you do,
you'd see that the PHP code out there is not always 'clear & clean'.
Current interfaces are a very good thing as they actually enforce
something which you can rely on. Maybe-interfaces....
Another thing is that your example with PSR3 logger still fail to be a
compelling argument because they are localized examples.
What would be more likely in a medium/big project? See a class
implementing a full blown interface like PSR3 or a
PunyPSR3LoggerInterface and then adding functions whenever they are
missing from the interface in the end having the same thing as PSR3?
(it's just an example since it's easier to pick up).
Again, the idea is good, the quality of the code will be ruined and
the profits for it are minimal while there are some big disadvantages
>>
>> I understand your idea, but for me, the problem that would generate in
>> real world scenario where you have junior programmers, trainees,
>> people that don't test the code before they deploy it (or that don't
>> write tests at all, like me).
>
>
> 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.
Do you think I'm saying this will make the code worst for average
people because I don't like the feature or because I've seen what
people are capable of doing in general?
And please be a sport and include a disadvantages section as well in
the RFC, since people would also find it easier to provide feedback on
this (not repeat the same arguments over and over) and at the end of
the day decide if the advantages outweigh disadvantages.
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
