On Wed, Jun 26, 2013 at 4:28 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Stas and all,
>
>
> But instead a fatal "protocol does not match" error will be thrown. The
>> difference?
>
>
> A recoverable protocol does not match error. And the difference is that the
> check is pushed to the caller as opposed to within the function.
>
>
>> > It gives the ability for a method to be defensive by preventing E_FATAL
>> > errors. That's not adding something significant?
>>
>> I fail to see the difference between one error and another error. The
>> whole "catchable" thing is very artificial difference and as far as I'm
>> concerned, if that's the problem, just make method-not-defined
>> "catchable", whatever that might mean - there's no difference on the
>> substance that I can see.
>
>
> I think we should. And I think we should turn all non-engine related fatals
> into exceptions. But both are beyond the scope of this proposal...
>
>> I agree the use-cases are slightly weak. This is a draft RFC. It's
>> > supposed to help identify the areas where we can improve it. Help
>> > identify use-cases. Help dig it out.
>>
>> My personal opinion regarding design always was that use cases come
>> first. If I don't have a use case, there's nothing to design. So I'd
>> like to see the convincing use case first. Then, once it's convincing,
>> we can talk about implementation details - so yes, you can discard all
>> the performance, etc. talk - it's not important right now, the most
>> important thing is the use cases.
>
>
> The use-cases did come first. Unfortunately they are not trivial to type
> out, and they are not trivial to really understand without actually playing
> with code. Which is one reason for this draft proposal... So that people
> can actually download the code and try it out. So that new use-cases beyond
> my own could be fit. So that people could try it out and comment and evolve
> the concept.
>
> As far as "discard all the performance, etc talk", it was Laruence and
> yourself that brought that up here. And it's something that a lot of people
> have jumped on. I find it funny that I have proven at least 3 times in this
> thread that performance is equal to or faster than the current interface
> approach, yet it still keeps getting brought up... Funny how arguments that
> support a stance are thrown around, even when they are disproven (and then
> they are at best ignored)...
>
> Additionally, I'd like to make a note here. There's been a lot of talk
> about "best practice" in this thread. I think that's exactly the wrong way
> that language features should be judged. What's currently accepted as "best
> practice" is subject to change over time. In practice it does. Just look at
> the past 5 years of development in frameworks. We went from completely
> Class-Oriented procedural codebases like Cake and ZF1 to completely OOP
> designed frameworks like Symfony and ZF2. What the "cool kids" in the
> community (the only way I can really describe the vocal minority of OSS
> contributors) consider "best practice" has changed Dramatically in the past
> 5 years. Hell, it's changed drastically in the past 5 months.
>
> Internals should not be taking sides on what's good practice and what's bad
> practice (if it was, why the heck was goto introduced?). Instead, it should
> enable today's good practice to be followed. But it should not take a stand
> about bad practice.
>
> It's a slippery slope to make the "best practice" stand. For example, one
> could make the argument that ignoring errors is not best practice, so
> therefore every non-truely-fatal error thrown by PHP should be an
> exception, to force the user to not ignore it. Reasonable? I don't know.
> But if you want to go down the "we need to follow best practice" route,
> that's the logical conclusion...
>
> My point here is that we should be judging features by their merit alone,
> and not by how we would use them. We also should not be judging them based
> upon our preferred style, but on the overall case of what it aims to
> achieve.
>
> Bringing this back on point, Duck-typing is a very valid and accepted way
> of doing OOP. In fact most other dynamic languages use this as the basis
> for their OOP system. This proposal does nothing but attempt to allow a
> little more safety and self-documentation to a use-case that today is
> pretty free-for-all...
Hey,
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 :)
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?
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.
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).
Can you please address these issues?
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
