Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58000
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
Received-SPF: pass (google.com: domain of keisial@gmail.com designates 10.216.135.15 as permitted sender) client-ip=10.216.135.15;
Message-ID: <4F47B2DC.30909@gmail.com>
Date: Fri, 24 Feb 2012 16:55:08 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Kris Craig <kris.craig@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>
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>
In-Reply-To: <CAKOpQSzOXBoHji-3h-suNHQxydqkMEjQ_HS_+rL=_JoOeBt68g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
From: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)

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).