Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80051
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.44 cause and error)
Message-ID: <54A56EB3.2000308@fischer.name>
Date: Thu, 01 Jan 2015 16:58:43 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>
CC: internals@lists.php.net
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A5051F.1090400@php.net> <54A52AE6.70704@fischer.name> <CDBE6BAD-1345-432B-AE0A-3160697BBF05@ajf.me>
In-Reply-To: <CDBE6BAD-1345-432B-AE0A-3160697BBF05@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hello Andrea, On 01.01.15 16:19, Andrea Faulds wrote: > I
   think it’d be weird to have different syntaxes for scalars and non-scalars.
    We already use the syntax the RFC proposes in the PHP manual, and I don’t
    think anyone’s confused by it. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: markus@fischer.name (Markus Fischer)

Hello Andrea,

On 01.01.15 16:19, Andrea Faulds wrote:
> I think it’d be weird to have different syntaxes for scalars and non-scalars. We already use the syntax the RFC proposes in the PHP manual, and I don’t think anyone’s confused by it. 

I didn't meant to stay there's something wrong with the syntax, sorry if
my text was confusing! I was rather trying to point out that it does not
hint at anything but proactively tries to convert types; see below for more:

>> 2. Casting and Validation Rules
>>
>> "While this RFC merely follows PHP's existing rules for scalar
>> parameters, used by extension functions, these rules may not be familiar
>> to all readers of this RFC."
> 
> Yes and no. With the exception of hexadecimal numbers in strings, explicit casts and internal functions follow the same rules for conversion. However, the validation rules don’t match. Explicit casts never fail, while internal functions will reject arguments that are non-scalar or don’t fit certain rules.
[...]
> 
>> 3. "Non-numeric strings not accepted. Numeric strings with trailing
>> characters are accepted, but produce a notice. "
[...]

>> What's the point of continuing the code when developer asked for "int"
>> and code logic continues with "something not quite an int"?
>>
>> Doesn't that defeat the whole purpose of the use of this RFC?
[...]

> 
> I can’t say I love that behaviour either. It is, however, our existing behaviour. I’d rather we be consistent with internal functions.

And as you also pointed out: those conversion rules are different from
what a plain "(int)$whatever" would do.


I completely understand the technical ratio here: internal function have
an existing argument/parsing system which is now exposed to the end
developer ("php user") here.

I argue this system is fit and works (and, err, talk BC; obviously!) for
the whole internal PHP function/method system but ..

.. does not reflect the needs and requirements of a php user/developer
because exactly of these implicit conversion rules with three different
output states (everything ok, hard type mismatch, notice on partial
conversion).

I'd also argue that scalar types in function signatures behaving
differently than object type hints is potentially a bad thing for future
of PHP and I already made my point which is the most important to me:

>> What's the point of continuing the code when developer asked for "int"
>> and code logic continues with "something not quite an int"?



Now, going on step back here (talking about me), I'm speaking up because
>my< needs are developer are different (mostly speaking about backend
code, interfaces, libraries, frameworks) but OTOH I'm not a big known
open source framework developer either ;)

I would honestly be interested what the big framework/library players
actually want/need; do they prefer this implicit scalar type conversion
system or rather have a rigid system like the current object types but
for scalars too? I think decision on this RFC should include also
"their" saying too.

It's complex because we can't force anyone to participate but I think
above all these are the most important audience here because they know
what they want and they know what their users want. I say this because
usage of object types in PHP is almost non-existent (or, there are just
too few cases) compared to the architecture of some of the
framework/library systems out there.

Hmm.

thanks,
- Markus