Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84076
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54F18744.4040303@lsces.co.uk>
Date: Sat, 28 Feb 2015 09:15:48 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com> <CALWK-fghdLMjt5yMMb23mnf0dNt+Mnx_tOYdLopfxLZFZvzTKA@mail.gmail.com> <0bc601d0532f$f6296260$e27c2720$@php.net>
In-Reply-To: <0bc601d0532f$f6296260$e27c2720$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: lester@lsces.co.uk (Lester Caine)

On 28/02/15 08:24, François Laupretre wrote:
> Sorry, not a bug. Documentation is clear. You get 'string|false' from substr() and send it to a function expecting 'string'. Most languages will fail on this. It worked in PHP because of implicit casting from bool to string. We just decided to deprecate this implicit cast.
> 
> Now, we can discuss about substr(), whether it should always return string or not. But that's another subject.

Isn't this the whole crux of the problem?

The strict/coercive world fix for 'is there a string left' is to create
an error which has to be handled, when workflow wise simply branching on
the empty string is the correct action. I can see that some people need
the empty string rather than the 'false' but THAT is the sort of thing
that 'Coercive' should be handling rather than dictating that it is now
an error.

This is fundamental to the nature of PHP and dismissing a basic premiss
'another subject' is exactly what both 'camps' are currently doing. *I*
want to maintain the ability to write code that runs in sequence, that
is what a script language should do. It is NOT designed to be compiled,
but processed and having to compile sections to create new functions
such as exception returns which may never be used is wrong, just as
trying to optimise something that may need the now optimized out element
next time a bit of code is used is equally wrong. If you want the
ultimate fastest performance just use C or one of the other fully
compiled languages an live with the 'delay when you first run it'.

Ultimately PHP works because it returns the type of object you need at
the time ... fixed single types are not what PHP is ... and that is the
type of PHP *I* want but I seem to be in an obsolete minority? I only
need the current build of PHP7 because it puts back speed lost due to
other changes but it is most definitely heading somewhere I don't want
to be.

-- 
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