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*...
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.
> 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++).
> 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
