Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67952
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nHWJYkB0sFWNep=QJqVX7+QsKJ-ne=rD7Qszs98DDx3aA@mail.gmail.com>
References: <CAAyV7nGo4+n_4Ad7oKyuvLWTtmnui7fn6s-noCwG2PtT5A70tQ@mail.gmail.com>
 <51C9FA9C.8050403@sugarcrm.com> <CAAyV7nHz0E2Tmin5_S4OVii=U1HhuKKL6y_KAa+j=X7DT9My6g@mail.gmail.com>
 <51CA1C93.6080500@sugarcrm.com> <CAAyV7nHo-ZLx2F=+6URctZXTqx8tLgR=xG7j0wJ3unmiCxGvXQ@mail.gmail.com>
 <51CA24C5.9090505@sugarcrm.com> <CAAyV7nG2Lmo0q01KGbKpBzpJXbs-2E+1ir8yCOFnN8yC-Up2Gw@mail.gmail.com>
 <51CB167A.4020207@sugarcrm.com> <CAAyV7nHWJYkB0sFWNep=QJqVX7+QsKJ-ne=rD7Qszs98DDx3aA@mail.gmail.com>
Date: Thu, 27 Jun 2013 16:52:23 +0200
Message-ID: <CALtuQzAGqipXCi-1bDmbDz91OK7KXrrpfa-Fn9xREKyaJYKjpQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bfcf01e4fdce604e023eb39
Subject: Re: [PHP-DEV] RFC: Protocol Type Hinting
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7bfcf01e4fdce604e023eb39
Content-Type: text/plain; charset=ISO-8859-1

2013/6/27 Anthony Ferrara <ircmaxell@gmail.com>

> 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 ;-)...
>

You havent talked to me, but I bring my voice in.


>
> 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)...
>



-- 
github.com/KingCrunch

--047d7bfcf01e4fdce604e023eb39--