Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57050
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: <4EF3D18B.7040900@sugarcrm.com>
Date: Thu, 22 Dec 2011 16:55:39 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Will Fitch <will.fitch@gmail.com>
CC: =?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?= <keisial@gmail.com>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <2095305E-D4E3-4D7E-8218-32EE99688E0C@GMAIL.COM> <CAF+90c-Wtok1fnVxokYUFQhbYnMcNDwWWT63F8NDp+JnxCDMew@mail.gmail.com> <2C90FB94-38C4-4270-8C6A-B89304BA8ED8@gmail.com> <CAEZPtU6gneOOehrsz-qVifmNxg6tnyLt9hqfnAwKZmfpXdeC9Q@mail.gmail.com> <159A7CA2-8561-40DA-9434-CAAE12304DDB@gmail.com> <4EF3B56A.4040809@gmail.com> <-2451498990672032588@unknownmsgid> <4EF3BD21.2040301@sugarcrm.com> <-6952580475866195972@unknownmsgid> <4EF3C7F7.9010404@sugarcrm.com> <4841689055873111589@unknownmsgid>
In-Reply-To: <4841689055873111589@unknownmsgid>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> And in those cases, they would continue to use the keyword "function"
> and be considered unknown as they are today.

Taking the most common case and ignoring it and saying "ok, then don't 
use it" is not a good way to design a feature in a general-purpose 
language that would be used by literally millions.

> I don't compare PHP to ruby, python or JavaScript. Do I suggest
> features that I find useful in other languages like C# or Java or even
> in any of the ones you listed? Absolutely.

C# and Java, again, are fully statically typed compiled languages. PHP 
is not. That means that the benefits of strict type system that are 
available to programmers in C# or Java will not be available to PHP 
programmers, while the downsides of it (and inflexibility that such 
system leads to) will still be there and will actually be multiplied by 
the fact that you wouldn't know about the problem with your typing 
system until your application starts crashing.

> add overhead, just as parameters do (arguably more). But it is a
> feature that is very valuable to many. Those who wish not to use it
> can continue to do so.

Sorry, again, "don't use it" is not a valid response for a core feature 
in a widely used language. It would be OK for a PECL module - if you 
don't like mongoDB, don't use it, nobody objects to having mongodb 
extension because it is not fit for some scenarios. However, designing 
core language features that change the nature of the language - making 
it from non-typed to strictly typed - have bigger requirements. You can 
not just "not use" core feature - because others will be using it and 
you'd have to leave with it and interface with their code.

> Don't forget that while return checks are runtime, interface
> definition and implementations are compile time.

Nothing is compile time in PHP, PHP has no compile time (at least if we 
don't consider projects like HipHop, which is totally irrelevant here) 
like C# or Java does. That's not how PHP code works. In C# and Java, you 
can take the code and know in advance the type of any piece of data in 
any place (maybe not precisely but at least base type). In PHP, you can 
not.

> Because null is a standard already set by parameter type hints. I do
 > not want to sway away from that as it works well.  It is common for

I'm not sure what you're talking about as a "standard". Yes, input 
parameters strict typing allows nulls because it was another frequently 
used scenario that strict typing does not support.  Fortunately, it 
could be fit into "default value" syntax, even though it doesn't really 
means that (so we actually have a syntax that means two different things 
now, not a great idea). But with return types and value strict types 
(which would inevitably be asked for next) it wouldn't be that easy. 
There's no syntax for "default return value" and the case of returning 
false - one of the most common - can not be covered. And, on top of 
that, I still do not see any benefit of it as you'd still have to check 
the return value anyway!
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227