Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58415
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.236.184.167 as permitted sender) client-ip=10.236.184.167;
MIME-Version: 1.0
In-Reply-To: <CAJzDObcoCsAYUxEoYBkkro4HSeN7ytd=4or3h-cZwzTzFqo2vg@mail.gmail.com>
References: <CAJzDObfZpPCBc18pTOyxT8aCLzp801Vg9L_uj9HR=gg5geGKLQ@mail.gmail.com>
 <CAMyk_AZbuBYaDKigKxCSCP0=VNJPHJSNsicjVyDm78nJe2LMwA@mail.gmail.com>
 <CAJzDObeGJqtU2FdyfcdNdUO=eeXg6mOZ7iycbqwqH8unD_KxeQ@mail.gmail.com>
 <CAMyk_Ab3LO9erovz9XgF5q6ephm0=P3oGEKiqLCrKhk9d7bx7g@mail.gmail.com> <CAJzDObcoCsAYUxEoYBkkro4HSeN7ytd=4or3h-cZwzTzFqo2vg@mail.gmail.com>
Date: Thu, 1 Mar 2012 16:36:20 +0100
Message-ID: <CAMyk_AZEs=GC6qe3rABbmc3HDFcBcSGhwPQ-UqBppTENq=+kRA@mail.gmail.com>
To: Adam Jon Richardson <adamjonr@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf303f6accf1c12104ba30399d
Subject: Re: [PHP-DEV] Scalar Type Intentions
From: linepogl@gmail.com (Lazare Inepologlou)

--20cf303f6accf1c12104ba30399d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> Of note, the scalar type hinting I've outlined does not automatically
> perform casts...


Thank you for your answer. Maybe, this exact fact is what I don't like
about your suggestion. Please read the following RFC, where Lukas Smith and
Zeev Suraski explain very well why strict type checking without
auto-casting is a not a great idea. Of course it is just an RFC, but I find
it quite correct.

https://wiki.php.net/rfc/typecheckingstrictandweak


My concern is that if your suggestion is adopted (as it is, without
auto-casting) then an eventual introduction of auto-casting will be
impossible without breaking BC.


Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel


2012/3/1 Adam Jon Richardson <adamjonr@gmail.com>

> On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou <linepogl@gmail.com>wr=
ote:
>
>> Yes, I agree, the casting (or the failing to cast) has to happen on
>> entry, for the reasons that you have very well explained.
>>
>> However, I cannot understand what it means to cast an object to a scalar=
.
>> Does it always mean casting to string? Wouldn't that be slow in many cas=
es?
>>  Simple example:
>>
>
> I'm not sure I understand, so if I mischaracterize your concerns, please
> let me know.
>
> Of note, the scalar type hinting I've outlined does not automatically
> perform casts to any particular type of scalar. Rather, it would be the
> programmer's responsibility to perform the cast (as I performed in my
> example.) This way, only necessary, reasonable casts are performed, and
> information loss can be avoided.
>
> That said, in terms of performance, PHP's type juggling performs these
> types of casts all the time, so I don't think I'd be concerned. Any time =
we
> check for equality using =3D=3D, perform string concatenation with ints, =
etc.,
> PHP's beautiful type juggling automatically performs these conversions fo=
r
> us without any effort on our part. I've never seen where this is the sour=
ce
> of any performance issues in my profiling, but I must admit that I don't
> know the internals well enough to preclude this from ever being an issue.
>
> class A {
>>   public $value =3D 1234;
>>   public function __toString(){ return (string)$this->value; }
>> }
>>
>> function foo( int $x ) {  // here "int" is used as an alias to "scalar"
>> as you suggest
>>   return $x + 1;
>> }
>>
>> $a =3D new A;
>> foo( $a );  // casting $a to scalar upon calling, as it is possible
>> after all
>>
>> In this example, the integer value will have to be cast to a string only
>> to be cast back to integer (unless something else happens under the hood=
s
>> that I am not aware).
>>
>
> Speaking to your example, it would throw a catchable fatal error because
> the variable $a contains an object of type A and the function foo expects=
 a
> scalar. The object would first have to be cast to a scalar. However, as y=
ou
> pointed out, currently objects can only implement the __toString() method
> (i.e., there's no __toInt, etc.), so one can't directly cast an object to
> an int.
>
> This seems contrived, though, because in the case of your example, if a
> function expects an integer, wouldn't you just call it with the appropria=
te
> object property:
>
> foo ($a->value); // works because the value property is a scalar (int)
>
> Thanks for your commentary :)
>
> Adam
>
>

--20cf303f6accf1c12104ba30399d--