Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57993
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.180.99.100 as permitted sender) client-ip=10.180.99.100;
MIME-Version: 1.0
In-Reply-To: <CAKOpQSzOXBoHji-3h-suNHQxydqkMEjQ_HS_+rL=_JoOeBt68g@mail.gmail.com>
References: <CAG=uTXFQUY=EDb=ut97nNSm+m8sMQNRK-9YPcfb2quaoS246-g@mail.gmail.com>
	<CABBJUpd7XkDjckY-5=D6B=kouUYMrWvzMVnHR_Hch74oGWM-TQ@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>
Date: Thu, 23 Feb 2012 15:39:18 -0800
Message-ID: <CAKOpQSwa6jhbbRBhNyvRQKEhW2zn+YLHimYJUi=EF-5kj-x5+Q@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=f46d04428e5c21998304b9aa278e
Subject: Re: [PHP-DEV] [RFC] Enum proposal (yet another)
From: kris.craig@gmail.com (Kris Craig)

--f46d04428e5c21998304b9aa278e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Err typo correction:  In my "what if" scenario, I meant to say, "what if
dynamic function A makes a call to *static* function B".

--Kris


2012/2/23 Kris Craig <kris.craig@gmail.com>

> 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?
>
> 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.
>
> 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 t=
he
> required type.  Personally, my vote would be for Option 2.
>
>
> I know this would be potentially confusing to people who are used to the
> existing language structure, but it's also worth noting that PHP has
> already changed quite a bit over the years and we've all managed to adapt=
.
> I'm thinking this would be perfect for PHP 6, since it would not be at al=
l
> unreasonable to assume that there would be significant language changes
> that might require a slight learning curve at first, just as PHP 4 and 5
> did.
>
> This is perhaps the most common complaint I hear about PHP.  There are
> many programmers out there who think we're out of our minds (or just plai=
n
> lazy) for not acting on this.  I'm not one of them, mind you, but I can
> certainly see why they'd think that looking from the outside.  I think it
> would be really awesome if we decided to finally tackle this head-on,
> despite the obvious discomfort that it would bring in the short-term;
> though I think much of that could be mitigated if we simply targetted thi=
s
> for PHP 6.
>
> --Kris
>
>
>
> 2012/2/23 =C1ngel Gonz=E1lez <keisial@gmail.com>
>
>> On 23/02/12 23:49, Kris Craig wrote:
>> > Yeah I agree, that was one of the things I listed under
>> > "disadvantages" lol.
>> >
>> > I guess my question is:  Does this constitute a prohibitive problem,
>> > or is it something that we can stomach?
>> >
>> > I mean, if you think about it, that's really what we're talking about
>> > anyway, right?  After all, when you're writing any application, you're
>> > either going to be writing it with strict typing or you're going to be
>> > writing it with dynamic typing.  The only difference here is that
>> > coders with either preference will both find PHP accommodating to
>> > their style.
>> >
>> >
>> > Similarly, a somewhat weaker argument could be made that, in PHP 5,
>> > you're either coding for procedural design or for OO design
>> > (technically you could do both, but I wouldn't wanna touch that
>> > codebase with a ten foot poll lol).  The only difference here is that
>> > there would be a config setting to tell the interpreter which is which=
.
>> >
>> > --Kris
>> I think you would get developers coding for strict, and hostings set to
>> weak. Makes more sense to have it as a per file / per function
>> attribute, so the author can choose if they want the values passed to it
>> to be coerced or act as if they were doing a manual check and throwing
>> an exception.
>>
>>
>

--f46d04428e5c21998304b9aa278e--