Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:49339 php.internals:49340
Return-Path: <rpanning@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 28778 invoked from network); 11 Aug 2010 14:55:33 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 11 Aug 2010 14:55:33 -0000
X-Host-Fingerprint: 64.8.134.189 unknown  
Received: from [64.8.134.189] ([64.8.134.189:17866] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id B0/D4-01618-4E9B26C4 for <crocodile2u@gmail.com>; Wed, 11 Aug 2010 10:55:33 -0400
To: internals@lists.php.net,Victor Bolshov <crocodile2u@gmail.com>, smalyshev@sugarcrm.com
Message-ID: <4C62B9E0.4030305@gmail.com>
Date: Wed, 11 Aug 2010 09:55:28 -0500
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
CC: 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>	<4C61D6D0.90907@sugarcrm.com> <AANLkTinATNjUXa1WUNBpFu0tL8LTd091H1jRPP9iiRSv@mail.gmail.com>
In-Reply-To: <AANLkTinATNjUXa1WUNBpFu0tL8LTd091H1jRPP9iiRSv@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
X-Posted-By: 64.8.134.189
Subject: Re: [PHP-DEV] Strict typing
From: rpanning@gmail.com (Ryan Panning)

Victor Bolshov wrote:
> Having two similar syntaxes that work differently - would make the
> situation even worse that it is now - I beleive. And I totally agree
> with Rasmus - strict typed language mustnt be called PHP. (Just a poor
> user's notice to all of you internals' geeks out there)
> 
> 2010/8/11 Stas Malyshev <smalyshev@sugarcrm.com>:
>> Hi!
>>
>>> 1. right now we *have* strict type checks for classes and arrays in the
>>>    form of "classname" or "array"
>> Because classes and arrays were never intechangeable types and there was
>> never implicit or explicit conversion between SplRecursiveTreeIterator and
>> Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always
>> was conversion between int and string or int and bool. These two things are
>> completely different.
>>
>>> 2. the strict scalary type hint patch reuses this same syntax in the
>>>    form of<type-name>  to do the same thing in function arguments
>> It's not a good thing. As I mentioned, primitive types and classes are very
>> different in their use cases and established patterns in PHP. Primitive
>> types are largely interchangeable, classes are not. (As for arrays, arrays
>> really should be a class by their usage patterns etc. but for historic
>> reasons... you know)
>>
>>> 3. we have casting type hints in the rest of the code in the form of
>>>    "(int)".
>> Just to make it simpler and less confusing, of course. It's nothing like
>> language having two features that look almost exactly the same but work in
>> different way, and using plenty of ()s is an added bonus for all Lisp fans
>> out there.
>>
>>> Some people don't like strict typehints, but the syntax as it currently
>>> is regarding type hints is *consistent*. Now, to allow both strict and
>>> casting hints, the logical step seems to be, to give the weak typehint
>>> advocates their tool as well:
>> Calling something that works completely differently from all the established
>> patterns of PHP - like internal functions, etc. - "*consistent*" requires
>> totally new definition of this word.
>> --
>> Stanislav Malyshev, Software Architect
>> SugarCRM: http://www.sugarcrm.com/
>> (408)454-6900 ext. 227
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

Why do you think the two syntax's would be more complex!? IMO it is very 
clear what each would do.

The "strict type hinting", foo(int $var), is the same as the current 
"type hinting" for classes and arrays. It's required to be of that type, 
plain and simple.

The "weak type hinting", foo((int) $var), is the same as casting any 
other var, plain and simple. It will try to be casted to the specified 
type, with an error if it can't.

I'm willing to bet that if you bring this to the end users they will 
agree that it's easy to understand. Why try to figure out a new syntax 
for something that already exists!?

Now, changing the current implementation to "weak type hinting" would be 
more confusing. Because the current syntax used for type hinting 
classes/arrays is strict. If changed, you would need to specify that 
scaler types are weak but classnames are strict and now you have a WTH 
moment.

Not sure how much my opinion matters here though because I'm just an end 
user of PHP. IMO some of these debates should be brought to the end 
users. Who uses PHP in the end? The users. (And yes, I know the devs 
here do to..) What is one thing most companies go by? The customers come 
first. This "we know best" attitude here is gone way to far. Please 
don't just leave this here, because you'll hear it from the users in the 
end anyway. A good community is one who communicates. Thanks