Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80039
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.36 cause and error)
Message-ID: <54A52AE6.70704@fischer.name>
Date: Thu, 01 Jan 2015 12:09:26 +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: internals@lists.php.net
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A5051F.1090400@php.net>
In-Reply-To: <54A5051F.1090400@php.net>
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 Sebastian, On 01.01.15 09:28, Sebastian Bergmann wrote:
    > Am 31.12.2014 um 21:27 schrieb Andrea Faulds: >> Parameter type hints for
    PHP’s scalar types > > Please use the term "type declaration for arguments"
    (or "type > declaration for parameters") instead of "type hints". If it's
    used > then it's not a hint. [...] 
 
 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 Sebastian,

On 01.01.15 09:28, Sebastian Bergmann wrote:
> Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
>> Parameter type hints for PHP’s scalar types
> 
>  Please use the term "type declaration for arguments" (or "type
>  declaration for parameters") instead of "type hints". If it's used
>  then it's not a hint.

Thanks for bringing this up.

Interestingly, from the RFC I had another issue with it: what it
technically does it neither "hinting" nor "declaration" but it tries
conversion and seem to have multiple action how it may continue:
- continue, everything as expected
- catchable error
- notices thrown

To Andrea:

As much as I'd like to see such a language feature like this, I think:

1. the naming of the RFC thus the intent is confusing

What it really does is it tries its best to convert, e.g. the RFC reads
as it tries to work like this:

function foo(int $bar) {
  $bar = (int)$bar;
}

From your description I understand that, technically, it doesn't do that
exactly; I was merely trying to make a point how it "looks it works";
see my next point.


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."

Very good job in pointing this out! Which brings me to this question:
are these different rules than the general casting rules (as I exampled
above) ? If yes, wouldn't this increase the burden on PHP developers
even more to learn new rules (and, those rules are already to many to
sanely remember).


3. "Non-numeric strings not accepted. Numeric strings with trailing
characters are accepted, but produce a notice. "

That behavior, IMHO, is very bad for this kind of feature.

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 know that this can be fixed using an error handler, throwing an
exception to abort code execution but that should really be an error
anyway, IMHO, on par with a gross mismatch of types.


I'm not in favor of these soft rules.

thanks,
- Markus