Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58770
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL0xaBGAHfOSR1g4meDsJfczBTR0dOfypBjHLXGT7h9o5T7eeA@mail.gmail.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>
	<60744d7ea642fe03c7110502a3f4276a@mohiva.com>
	<CAAyV7nGZdq+TYU3eiQXj5CtEkRs84u_oOXRB7m+RNseU1QtG+Q@mail.gmail.com>
	<CAL0xaBHC8vFSnuezWwWqsBczHZA3uvgpb+K3z3z87Mc2Gbeseg@mail.gmail.com>
	<CAJWj5+HDyBvMGN7HiHBBEswr67s=tEfsTd3mHbzfeAZRrVmB2w@mail.gmail.com>
	<CAL0xaBGAHfOSR1g4meDsJfczBTR0dOfypBjHLXGT7h9o5T7eeA@mail.gmail.com>
Date: Thu, 8 Mar 2012 10:36:30 +0100
Message-ID: <CAH-PCH5SkZw2rSsqp5rYvfWtqCmQK6P+vU67zOgPiZ6sZ+Xedw@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Simon Schick <simonsimcity@googlemail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b1118cdd2173b04bab802c9
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b1118cdd2173b04bab802c9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 8, 2012 at 10:03 AM, Arvids Godjuks <arvids.godjuks@gmail.com>w=
rote:

> Hi Simon!
>
> 2012/3/8 Simon Schick <simonsimcity@googlemail.com>:
> > Hi Arvids,
> >
> > I pretty much like this idea as it's more strict. Let me say something
> > to the questions you pointed out here.
> >
> > 2012/3/7 Arvids Godjuks <arvids.godjuks@gmail.com>:
> >> I realize that with scalars it's not that straight forward, but
> >> complicating things by adding an auto-cast syntax and so on is just
> >> ridiculous. Hints should stay, well, hints. The only problem we have
> >> is complications of accepting numerical strings or numbers as strings.
> >> And what to do with "null".
> >
> > I'd like to handle it the same way as it's handled with the classes
> > right now. If null is not the default-value you'll get an error when
> > you pass null in there.
> > One thing I'd like opened here: If you define a default-value
> > different than null, should you be able to pass null as well and the
> > compiler will use the default-value?
> >
> >> function a(bool $bool) {}
> >> a(10); // Kill your self against the wall - write a(true);
> >> If you define bool - use the damn bool!
> >
> > I like that. What should we do if this appears? As it's now - just
> > throw an "Catchable fatal error" and let the script blow-up? I would
> > go this far.
>
> I think "Catchable fatal error should" be fine and users are familiar
> with such mechanic because it already exists. Consistency, man,
> consistency :)
>
>
> >> I consider interchangeable only three cases:
> >> 1. Numerical string.
> >> 2. Integers and floats as strings.
> >> 3. Integer and string  0 1 as bool.
> >>
> >> Any other cases should error out.
> >
> > Until now I thought about the weak variable-types as a order ...
> > string, float, integer, Boolean.
> > All Boolean values are compatible be an integer (0 or 1) and all
> > integer are compatible to a float and so on. Do you think it's good to
> > have it this way? This would mean that you could also get a Boolean
> > true as string "1" ... I personally don't like that ... but I don't
> > know where to draw the strict-line.
> > Now think about that backwards. Can a "1" be passed as a parameter
> > that expects Boolean? If yes, I'd keep it consistent in both ways.
> >
> > Bye
> > Simon
>
> That's a good tricky question, I like it.
> Well, I think the lower should work just fine.
> function a(bool $int) {};
> a("1");
>
>
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar type
hints with the current implementation of zend_parse_parameters.
the built in php functions are "enforcing" the function signature via
parsing the parameters through this call.
so for example the above mentioned substr signature is substr ( string
$string , int $start [, int $length ] )
substr("foobar", "123"); // works like a charm
substr("foobar", 1.5); // works, no warning/notice, although we lose
precision here,
substr("foobar", "123 asd"); // Notice: A non well formed numeric value
encountered
substr("foo", "bar"); // Warning: substr() expects parameter 2 to be long,
string given

so if we would implement the scalar typehints in a way to map the signature
types to the zpp call, then that would mean that the scalar hints are
consistent across the built-in functions, the documentation, and the
dynamic nature of the language(as one could argue that the current/future
implementation of zend_parse_parameters is in line with the dynamic
casting/type juggling nature of php.

just my 2cents

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b1118cdd2173b04bab802c9--