On Thu, Jun 27, 2013 at 10:54 PM, Laruence <[email protected]> wrote:
> On Thu, Jun 27, 2013 at 10:35 PM, Anthony Ferrara <[email protected]> wrote:
>> Stas et al,
>>
>>
>> So, the question of what is the difference between the two errors
>>> remains unanswered. If the whole diff is that one of the errors has word
>>> "recoverable" in the message, it's not substantial difference at all and
>>> one that does not require new syntax and big change in the language.
>>
>>
>> I'm assuming that you do know the difference between E_RECOVERABLE_ERROR
>> and E_ERROR. And the difference is not trivial...
>>
>>
>>> > 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
>>>
>>> Can we please lay the goto argument to rest? The argument "goto was
>>> introduced, so feature X must too, because goto was introduced" didn't
>>> sound good even the first time...
>>
>>
>> I'm absolutely not trying to say we should include this because GOTO was
>> introduced. I'm trying to point out the circular nature of the argument of
>> good-vs-bad practice in general...
>>
>>
>>> > should enable today's good practice to be followed. But it should not
>>> > take a stand about bad practice.
>>>
>>> In my opinion, we should. We should not take into the language any
>>> concept that anyone considers useful in some particular piece of code.
>>> PHP language is very widely used, and we should consider how it would
>>> influence this huge ecosystem and if the overall effect would be
>>> beneficial and justify complicating (if there is one) the whole language
>>> system.
>>>
>>> Language is a system of thought and a system of approaching
>>> communication. IMO, this means it should have some principles and not
>>> just be a random bag of things that somebody at one point or another
>>> decided to stick into it, they should make sense together. PHP doesn't
>>> have the best reputation in this regard, but we are trying to make it
>>> better, not worse.
>>>
>>> It does not mean we should avoid change. It means we should have good
>>> reasons for change and carefully consider it. Good use cases IMO are
>>> prerequisite for that.
>>
>>
>> Of course they are. Use-cases matter. A lot.
>>
>> But "good practice" vs "not-good-practice" shouldn't be a
>> significant
>> factor, because your "good-practice" is different from mine. And unless we
>> as a group decide to stick to one interpretation (we haven't), then it's
>> kind of pointless to talk about good practice. If you want to vote based on
>> it, that's your prerogative. But in general I think that thought process is
>> dangerous for the community as a whole and for core...
>>
>>
>>> > 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.
>>>
>>> IMO there's no merit in the feature besides its use. That's the only
>>> merit a feature could or should ever have.
>>
>>
>> Ok, so then you agree that "best-practice" doesn't come into it at all...?
>>
>>
>>> > 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
>>>
>>> In fact, most other dynamic languages don't even have parameter typing.
>>> Neither Perl, Python, Ruby or Javascript have it. Let alone typing of
>>> the kind you suggest. What they have we have too. Duck typing for them
>>> doesn't mean what you propose - it means what we already have, checking
>>> type at the point of use. Check
>>> https://en.wikipedia.org/wiki/Duck_typing and
>>> see the examples - most of
>>> them don't have any typechecks.
>>> Referring to "most dynamic languages" while promoting this proposal is a
>>> bit misleading.
>>>
>>
>> Those other languages (all of them in fact) throw exceptions if the
>> function or method does not exist. PHP hard fatals. They can live with pure
>> duck-typing because their engines are designed to stay running, where ours
>> is designed to fall on its face. This proposal is one attempt to bring some
>> consistency and recoverability to the dynamic aspect of programming while
>> providing for the ability to verify APIs at the engine level.
>>
>> One thing I find interesting is that I have discussed this feature with
>> about 50 people at this point (quite a few at conferences and such before
>> actually proposing it), and the sentiment elsewhere (not on list) was very
>> predominately "this solves a ton of problems". I find it interesting that
>> on-list people seem to think that I'm making the use-cases up, and that
>> there's not really a problem to solve. I wish some of the other people I
>> talked to would speak up here ;-)...
>>
>> One thing to note is who the major audience for a feature like this is.
>> It's not predominately for 1st party developers (developers writing one-off
>> applications). It's not predominately for 2nd party developers (developers
>> writing frameworks and other applications that have few dependencies and
>> are intended to be used by 1st party developers). It is primarily for 3rd
>> party developers. These are developers that maintain code bases built on
>> top of 2nd party code, but meant to be used by 1st party developers.
>>
>> What does that mean? The average one-off application builder is likely to
>> not get much use out of this (it can be used, but the problems for this
>> group of people are mostly solved already). The average framework core-dev
>> (like Symfony or ZF) isn't going to get *much* benefit out of this either
>> (it can help in some areas, and they will use it, but it's not solving
>> major problems). The Drupals, Magentos and Fuel CMS's of the world. The
>> people who make plugins and modules for Frameworks and CMS's.
>>
>> Basically, the people who's lives will get MUCH easier with something like
>> this are the people who maintain code that has a lot of dependencies, and
>> that other people depend on (it sits in the middle of the dependency chain,
>> where code on both sides is outside of their control).
>>
>> So if you don't see the usefulness of this type of change, ask if you
>> maintain anything significant that fits that description. If you don't,
>> find someone who does and talk to them. Otherwise you may be unfairly
>> judging by ignoring problems that you personally don't have...
> what's going on here?
>
> Stas has been a core contributor for a long time, if he didn't meet
> such usage, then I think 80%(or more) people doesn't have this need
> either.
>
> to be honest, I don't think this is useful either... (in case you
> will doubt my qualification, let me introduce myself a little more, I
> am a 6 years PHP, 5 year C engineer, develped a lots of PHP
> applications, and also some big scalar ones, like weibo.com which I am
> maintaining now, thanks)
>
> interface is enough, interface is exactlly doing the protocol control
> thing, and I think it does very well. and it also very strict and
> reliable.
>
> so, why we need such feature that only a few people need it( if there
> really is some).
I missed one thing here, it should be:
why we need such feature that only a few people need it, and will
also make reset people confused, and most of other language doesn't
have it, and using it will make things a little mess(and low
performance vs pure interface)?
thanks
>
> and about the performance, runtime check on every methods's signature
> in runtime, how could it be faster than current way?
>
> if you bring 1% slowdown in one feature, yes, it's trivail, but if
> you bring such features 100 times?
>
> and, I have to clarifiy, the main reason I don't like this proposal is
> usage, not the performance..
>
> and last, I am poor at english, so I usually don't like to argue.
> sorry if I didn't make myself clear.
>
> thanks
>>
>> Anthony
>>
>> PS: I updated the RFC with a number of use-cases, including the ability to
>> hint on Traits (more specifically, the API of a trait)...
>
>
>
> --
> Laruence Xinchen Hui
> http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/