Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58400
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
Received-SPF: pass (google.com: domain of linepogl@gmail.com designates 10.101.175.2 as permitted sender) client-ip=10.101.175.2;
MIME-Version: 1.0
In-Reply-To: <CAJzDObfZpPCBc18pTOyxT8aCLzp801Vg9L_uj9HR=gg5geGKLQ@mail.gmail.com>
References: <CAJzDObfZpPCBc18pTOyxT8aCLzp801Vg9L_uj9HR=gg5geGKLQ@mail.gmail.com>
Date: Thu, 1 Mar 2012 10:36:07 +0100
Message-ID: <CAMyk_AZbuBYaDKigKxCSCP0=VNJPHJSNsicjVyDm78nJe2LMwA@mail.gmail.com>
To: Adam Jon Richardson <adamjonr@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636c9293cb8afad04ba2b31a2
Subject: Re: [PHP-DEV] Scalar Type Intentions
From: linepogl@gmail.com (Lazare Inepologlou)

--001636c9293cb8afad04ba2b31a2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> And, *what if PHP added the following aliases for the hint scalar*:

- bool

- int

- float

- string
>

If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.

Your suggestion has a future compatibility problem. The introduction of new
type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
"scalar", then there will be no way to choose which type casting method
should be chosen.


Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/1 Adam Jon Richardson <adamjonr@gmail.com>

> PHP currently allows users to provide type hints for functions and method=
s,
> although the type hints are currently limited to objects and arrays:
> http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
>
> Restricting the type hinting to arrays and objects makes sense, as PHP's
> type juggling (similar in many ways to JavaScript's), a core feature of t=
he
> language, performs automatic conversions between scalars as determined by
> context:
>  http://php.net/manual/en/language.types.type-juggling.php
>
> However, the lack of scalar hinting does limit the ability of a developer
> to declare his/her intentions for function/method parameters. A non-hinte=
d
> parameter expecting a scalar could be sent an object or an array, breakin=
g
> the expectations (and much of the time, the functionality) of the code.
> That is to say, there is a value in declaring what the parameter IS NOT,
> too.
>
> For example, the function below could have an object or array passed as t=
he
> first argument, even though the expectation is a scalar:
>
> function foo($arg){
>   // $arg is supposed to be a scalar and will be used as an int
> }
>
> *What if PHP added the hint scalar?* The example could be rewritten as:
>
> function foo(scalar $arg){
>   // $arg is supposed to be a scalar and will be used as an int
> }
>
> The idea is that the failure to send a valid scalar argument to the
> function would result in the same feedback that currently occurs when arr=
ay
> or object hints are not heeded. Now, the expectations for each
> function/method parameter can be explicitly declared (or, at least, more
> explicitly.)
>
> And, *what if PHP added the following aliases for the hint scalar*:
>
>   - bool
>   - int
>   - float
>   - string
>
> The function could then be rewritten as below:
>
> function foo(int $arg){
>   // $arg is supposed to be a scalar and will be used as an int
> }
>
> Now, the aliases wouldn't buy any more precision in terms of PHP's parser
> expectations. Your function/method parameters can only expect objects,
> arrays, or scalars. However, the aliases would allow developers to better
> communicate intentions AND provide more information for IDE's and static
> analyses tools. And, again, the use of the scalar hint and its aliases
> would preclude sending objects and arrays to functions expecting otherwis=
e.
>
> I realize this subject is heated, and people's patience has worn thin. I'=
m
> just hoping to toss out this idea I've had for some time while all of the
> concerns on both sides are still fresh in my head.
>
> Thanks for reading :)
>
> Adam
>

--001636c9293cb8afad04ba2b31a2--