Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49302
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.113 as permitted sender)
Message-ID: <4C61F3EF.5030409@sugarcrm.com>
Date: Tue, 10 Aug 2010 17:50:55 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Josh Davis <phpwnd@gmail.com>
CC: Arvids Godjuks <arvids.godjuks@gmail.com>, 
 Internals <internals@lists.php.net>
References: <AANLkTim7sNwZWyo8dQz-o6S=Tta-OGYqnDM0cDJX3A49@mail.gmail.com>	<1281478269.6608.292.camel@guybrush>	<alpine.DEB.2.00.1008102325440.29410@kossu.derickrethans.nl>	<AANLkTikaMfPERRH8bKqBj1ajf8muBrnQK_Gv6SZcObzK@mail.gmail.com>	<AANLkTi=OebDc73DMVCUj5RJnHzv_VS6gn0_uATxb32dr@mail.gmail.com>	<4C61E5CA.5070604@sugarcrm.com> <AANLkTi=_hPcCJYoH1v-G1vdwY2PY1aLhfDJNKwDLsK9T@mail.gmail.com>
In-Reply-To: <AANLkTi=_hPcCJYoH1v-G1vdwY2PY1aLhfDJNKwDLsK9T@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Strict typing (was: Typehints)
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> First of all, I am talking about the typehinting syntax and mechanism
> here. As Derick pointed out, current typehints are strict.

Talking about "strict" vs. "non-strict" for class types is meaningless. 
You can consider them non-strict if you want - they convert if the 
conversion is available, just like the rest of PHP, with only note that 
conversion is *never* available.
But it's just a semantic game because we are talking about different 
things here. Using the same syntax just confused you to think they are 
the same, but in PHP they are not. There are some languages where 
there's no primitive types or primitive types aren't different from 
classes - but PHP, for better or worse, as of now is not one of them.

> Secondly, I don't support amalgaming userland with internal functions.
> If I was to treat those internal functions as if they were written in
> userland, I'd say that they don't use scalar typehints, specifically
> for the reason you mentionned. Internal functions just typecast
> whatever you throw at them, no question asked.

Again, it's just semantic games - you can call it "typehints" or not, 
your choice, but the fact is they did not fixate on the bitwise 
representation of the types - and we shouldn't start fixating on that 
now. They accept "1" when numeric value is needed, why can't you?

> Again, I'm not talking about internal functions but typehinting. Now,
> when a userland developer uses typehints it means they expect a
> variable of a certain type to be passed. If they want typecasting,
> Derick proposes a convenient way to do that.

That's exactly what is wrong with it - developer should NOT expect 
"variable of certain type to be passed" (if we are talking about 
primitive types), because PHP is not a strictly typed language, it's a 
dynamic language. There could be strictly typed language with PHP 
syntax, no problem, but that would a) require much more than just 
function parameters and b) not be PHP.

> The current typehinting system does not typecast. Changing that
> behaviour makes it ambiguous. It introduces a new behaviour grafted
> onto the old mechanism and without a new syntax.

It does not change any behavior - right now there's two sets of objects 
in PHP - primitive types and classes. Values of primitive types can be 
converted into another type, implicitly or explicitly, objects of 
classes can not.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227