Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F570EBB.6030103@sugarcrm.com>
References: <CAJRMtAGqZCWThbZVztGN3-FyQ4MkJAs=uO_V-6pUCy9q2aAaZw@mail.gmail.com>
	<CAKOpQSyas7HSDXD5bftK9o18ucYAfQvxRtTUjYOgRSv_4nY-9A@mail.gmail.com>
	<CAJWj5+EQhhYDTh8DHwv2N4pk8FQybX3P5H292BGixbHSLB7k3A@mail.gmail.com>
	<CAAyV7nGQFrMoneDKvr0s1djOOkjn6rMj6PJcuB0842eA8EefOw@mail.gmail.com>
	<52.38.15021.3A1E65F4@pb1.pair.com>
	<4F570EBB.6030103@sugarcrm.com>
Date: Wed, 7 Mar 2012 08:19:57 -0500
Message-ID: <CAAyV7nE_Xv+6wLzQOgx=N2At2UstEY8ucPLtDQkCjRyujQmmFA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: ircmaxell@gmail.com (Anthony Ferrara)

Stas,

Thanks for the comments!

inline.

On Wed, Mar 7, 2012 at 2:31 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrot=
e:
> Hi!
>
>>>> https://wiki.php.net/rfc/parameter_type_casting_hints
>
>
> Just took a look on it - the syntax proposed there is quite ugly and rath=
er
> confusing, I really wouldn't like to have such syntax in PHP.

Ok, this is where I'm torn.  I have a few (read: about 4 or 5)
responses (mostly from people I respect quite a bit) that say it's
quite ugly and confusing.  I have had a lot more responses saying it's
simple, elegant and syntatically draws the difference between casting
and strict type checking.  I see your point, I really do.  It's not
the prettiest syntax out there.  But confusing?  I'm not so sure...  I
think you're too close to the problem to really understand it.  Or
perhaps I am...  I don't know.

But based on the conversations I've had with all sorts of devs about
this (some that I don't know personally, some that I do, some junior,
some senior), the vast majority of them got it without explanation.
The fact that cast syntax was re-used gave them enough of a hint as to
what it was doing that they guessed correctly.  Now, if you think it
should be doing something different, then definitely re-visit the
syntax.  But if it's going to be casting variables, the syntax does
make sense and carries an intrinsic value with it...

> Also "(int) $foo =3D =931=94 will generate an E_COMPILE_ERROR" makes no s=
ense to
> me.

Actually, that makes perfect sense to me.  Think about it from the
reader perspective.  Sure, "(int) $foo =3D '1'" is pretty straight
forward, but what you you think if you saw:

foo ((string) $bar =3D 123);

Frankly, that would confuse the daylights out of me, and would force
me to stop and think about what would happen.  That's exactly what I
would like to avoid, the thinking step on reading it.  In fact, it
would make even less sense, since it would need to be cast, so the
following would return false:

function foo((string) $bar =3D 123) {
    return $bar =3D=3D=3D 123;
}
foo();

How much more confusing is that?  By restricting the default parameter
to be of the type being casted to, that sort of a problem wouldn't
happen and would be adverted by the compiler...

I think the difference is that I know that strings are not integers
and vise versa.  Even at the language level there are subtle
differences in behavior between the types, even if they store
equivalent values.

> Also, this line:
> function test((int) $intParam, (string) $strParam =3D "foo", (array) $arr=
ay)
> {}
>
> is not proper PHP code - it contains optional parameter and then paramete=
r
> with no default.

It is proper PHP code.  It parses just fine
(http://codepad.viper-7.com/rEHqZp).  Sure, it's not best practice
(and was an accident which has been fixed), but it's 100% valid and
proper PHP code and doesn't even raise E_STRICT errors...

> And can we please stop using word "hinting"?
> We can call it type conversion, typecasting, type coercion, etc.
> http://en.wikipedia.org/wiki/Type_conversion

Well, but I think that a distinction needs to be made about where it
is.  How about "Parameter Casting".  Better?

> But I don't see how there's any hinting involved.

The compiler (and any IDE) knows what the type of the variable will be
inside the function body.  How is that not hinting?

Anthony