Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75386
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53C24061.6050503@lsces.co.uk>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
	<53C2178E.7070705@sugarcrm.com>
	<53C24061.6050503@lsces.co.uk>
Date: Sun, 13 Jul 2014 11:17:31 +0100
Message-ID: <CABDNdAFKQidZPzTxO4NzmiA-ZVJ5dHGr8iRYVrhrBKpoSw3OcQ@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: pjsturgeon@gmail.com (Philip Sturgeon)

On Sun, Jul 13, 2014 at 9:16 AM, Lester Caine <lester@lsces.co.uk> wrote:
> On 13/07/14 06:22, Stas Malyshev wrote:
>> It is very direct specification of
>> either strict parameter typing or coercive parameter typing. I don't
>> think using confusing terminology helps anything here. I think it was a
>> mistake to introduce this term from the start and we should stop
>> propagating it.
>
> It does come across as as an attempt to hide the 'strict parameter
> typing' which is something that is very much less attractive. If I
> wanted that then I'd simply switch back to C/C++ direct which is perhaps
> where we are now heading anyway with the increasing use of pre-compiled
> application code?
>
> One of the reasons I persist with PHP is the fact that many of my users
> can adjust the odd PHP file correcting sequence or modifying text
> without having to learn the intricacies of formal programming. It's
> adding all these complex layers that is taking PHP away from it's more
> novice friendly base ... If you want a formal programming language then
> just use one?
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Type hinting worked as a phrase when classes, interfaces a traits were
the majority of what was going on. The fact that I can say I would
like a Foo and get a Bar (which extends or implements Foo) means that
"hint" is a perfectly valid word to use.

If we move onto scalars theb you two are both right, "hint" is no
longer a hint. It is too strict for hint to work, as it is a way to
specifically ask for a certain piece of data.

Now, if we can accept that and move away from arguing semantics, there
is a more useful conversation to be had:

Should we have this thing, regardless of the name?


To paraphrase Lester Caine's last message: PHP can't have nice things.


His argument is one that I see repeatedly on internals: "If you want a
formal programming language then just use one?"

I think this misses the point of why many people (myself included) use
PHP. Despite PHP's various and extensive list of often rather comical
flaws, I continue to use PHP (and probably will for another decade)
because it is the most popular language on the internet. I can ship
something that can be downloaded and installed by drastically more
people than other languages. Until that situation changes, I build
software like PyroCMS, release packages like those on The League of
Extraordinary Packages, help write standards for the PHP-FIG, and do
it all with this crazy hodge-podge language we all know and "love."

If I had the choice of picking and choosing whichever language I
wanted to use all the time, I would be using Python, Ruby, Hack, Go,
or whatever language I felt like using that morning, and I often do.
Because I don't always get that choice, and because I legitimately
_am_ stuck with PHP, I do like to see it continue to grow and improve
over time.

I believe I am not unique in this regard.

I, like Lester, do not want to see PHP get more difficult over time,
just because I am growing as a developer over time and eventually want
more and more formal features in the language. Luckily that is not
what is being suggested here.


Type hinting (strict parameter typing) is not some crazy C/C++ only
feature that junior developers will be entirely baffled by. I assume
at some point if you but a "square" into a $circle then you will get
an error, or a warning, or some sort of "Hi, this is wrong." which
will either be gob-smackingly self explanatory, or a quick google
away.

People here have often suggested that googling an error is a solution,
like the fantastic defense of T_PAAMAYIM_NEKUDOTAYIM a few years back
(and multiple times before and after):

"Come on people, what exactly is the problem with a once-in-a-lifetime
investment of 5 seconds of your time to google some stupid error
message. Something you, as a developer, spend your life doing.
Please, stop complaining about a minor (yes, it is minor, use the
fricking search engine!) annoyance and accept php's heritage."

If googling error messages is used as a reason to keep completely
useless things like T_PAAMAYIM_NEKUDOTAYIM, then that same argument
cannot be used as a reason to block genuinely useful features. One or
the other folks.


If we can move forward without anyone else saying "AAAH THATS C++" (or
my other favorite "AAAH THATS JAVA") then it would be interesting to
hear how people feel about this article, which covers a lot of the
difficulties of type hinting parameters in PHP:

https://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html

I'm sure you've all read it of course, but I would be interested to
see which of you support which approach.

If we can (for now) continue to use "hinting" without accusations of
being sneaky, then the RFC is discussion uses "Casting weak type
hinting." I would not hate to see "Casting weak type hinting" used,
but would prefer "Strict weak type hinting" myself.