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