Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Received-SPF: pass (google.com: domain of kris.craig@gmail.com designates 10.216.132.94 as permitted sender) client-ip=10.216.132.94;
MIME-Version: 1.0
In-Reply-To: <4F47B2DC.30909@gmail.com>
References: <CAG=uTXFQUY=EDb=ut97nNSm+m8sMQNRK-9YPcfb2quaoS246-g@mail.gmail.com>
	<CAO8n+WJrqUguS4FSq==z9rF6iLoz3uXqSLBrrkY6yMBY9DrTWA@mail.gmail.com>
	<CALtuQzD6f_vcZiGi2HWdP8SSqf9744FucUC+4sX7PnGhOnh+rg@mail.gmail.com>
	<4F455C96.50706@gmail.com>
	<4F455E91.2060408@alliantinternet.com>
	<028001ccf1ab$0b200050$216000f0$@alliantinternet.com>
	<4F457517.7050901@alliantinternet.com>
	<028d01ccf230$91d79b00$b586d100$@alliantinternet.com>
	<CAAyV7nHA_DhyZUqU2=EYDSvCEYmc7MFejsG97dXCoTtaeMurMg@mail.gmail.com>
	<4F4686C6.2040207@sugarcrm.com>
	<CAKOpQSwtHvSoSVj8q4_QTte42D588OUBDBQ_a4YB8q=GquekBQ@mail.gmail.com>
	<CAGsnKxbuT2WjsZdiEQEV58HkXzZBTYhzMUx4bD9oosEHF1PN_w@mail.gmail.com>
	<CAKOpQSzRAD6dVPHPfLXCjDYnd8EMmALegvWUEbJYeCrXp4yKRA@mail.gmail.com>
	<4F46BE01.7030007@gmail.com>
	<CAKOpQSxOmkKDxu09Z3mO9sQ9=JEOwE8w-Qewp0Y_rW-ohXhdtw@mail.gmail.com>
	<4F46C93A.1010108@gmail.com>
	<CAKOpQSzOXBoHji-3h-suNHQxydqkMEjQ_HS_+rL=_JoOeBt68g@mail.gmail.com>
	<4F47B2DC.30909@gmail.com>
Date: Fri, 24 Feb 2012 10:35:21 -0800
Message-ID: <CAKOpQSwPTXMHOtMPVxS+tbhiUcEotSpSu_K80+LpWgy_3XejxA@mail.gmail.com>
To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Cc: John LeSueur <john.lesueur@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	Anthony Ferrara <ircmaxell@gmail.com>, Dmitri Snytkine <dsnytkine@ultralogistics.com>, 
	Sebastian Krebs <krebs.seb@googlemail.com>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6da7d64f6044604b9ba05b5
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
From: kris.craig@gmail.com (Kris Craig)

--0016e6da7d64f6044604b9ba05b5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Could you elaborate on that a little?  I.e. "as an interface for the
call".  I'm not sure what you mean by that.  If you could provide a quick
example, that would be awesome!  =3D)

--Kris


2012/2/24 =C1ngel Gonz=E1lez <keisial@gmail.com>

> On 24/02/12 00:36, Kris Craig wrote:
> > Hmm that's a fascinating idea!  So, and please correct me if I'm
> > wrong, you're saying that it might be a better approach to determine
> > strict vs. dynamic typing on a per file or function basis instead of
> > on a per stack basis?  In other words, blah.php could contain two
> > functions, one using strict typing and the other using traditional
> > dynamic typing?
> Yes. Two functions in the same file with different conventions may be a
> strange use case, I'd expect differences to come from eg. using two
> libraries, each with different typing.
>
>
> > Theoretically, I think that approach could work.  Perhaps we'd have it
> > specified in the function declaration itself; i.e. "function whatever(
> > $text, $number )" would be a traditional, dynamically-typed PHP
> > function, whereas "strict function whatever( string $text, int $number
> > )" would use strict typing.
> I'm not keen with that syntax, but that could be discussed. I remember
> something similar was already mentioned in another types thread, with
> ideasl like string! or string? to mark the types as strict or weak.
>
>
> > The obvious question then would be, what if dynamic function A makes a
> > call to dynamic function B, passing to it a dynamically-typed
> > variable?  There are three viable approaches that come to mind:  This
> > count not be allowed; this could be allowed but only if the variables
> > being passed to function B are cast first (i.e. B( (string) $text,
> > (int) $number );); or, this could be allowed without casting, in which
> > case PHP would attempt to pass the variable and then throw an
> > exception if it cannot be parsed as the required type.  Personally, my
> > vote would be for Option 2.
> I was envisioning it just as an interface for the call. Thus, if funtion
> A used strict or dynamic types would be irrelevant. You seem to be
> bringing up another option however, which is that funcion A could
> specify the behavior on functions it calls.
> It can look appealing, but I don't think that's desirable. After all,
> it's the callee interface what is important, not the kind of caller (you
> could have a setting to force an stricter behavior, but that seems more
> appropiate for an extension, like xdebug scream option).
>
>

--0016e6da7d64f6044604b9ba05b5--