Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67896
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender)
Message-ID: <51CB167A.4020207@sugarcrm.com>
Date: Wed, 26 Jun 2013 09:27:38 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
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>
In-Reply-To: <CAAyV7nG2Lmo0q01KGbKpBzpJXbs-2E+1ir8yCOFnN8yC-Up2Gw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Protocol Type Hinting
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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...

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.

> 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...

> 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.

> 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.

> 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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227