Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57051
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <4EF3D18B.7040900@sugarcrm.com>
Date: Thu, 22 Dec 2011 20:40:02 -0500
Cc: =?iso-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8EE7D395-EDD5-4777-9AE1-1A543BFB5155@gmail.com>
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> <4EF3D18B.7040900@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
From: will.fitch@gmail.com (Will Fitch)


On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote:

> Hi!
>=20
>> And in those cases, they would continue to use the keyword "function"
>> and be considered unknown as they are today.
>=20
> 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.

The feature isn't designed around "only those who use it."  In fact, as =
per the RFC, the keyword "function" will be used to serve as a mixed =
return type.  There are cases where I don't want to type hint my return =
value from a method and will continue to use this.  All scalar values =
will be forced to use this way anyway.  Namespaces, interfaces, =
abstracts, closures, traits..... the list goes on with features that =
were built to give developers additional tools to use.  Are any of them =
required to use? No.  It's general purpose - just like the feature =
offered here.  How many features are built into PHP that are meant to =
force a user to use it, or even break BC?  Why would you suggest this is =
doing any different?  Can you provide an example where this feature is =
doing that?

>=20
>> 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.
>=20
> 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.

Are you saying parameter type hinting isn't in PHP? =20

>=20
>> 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.
>=20
> 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.

Sorry, again, look at what I said above.  Namespaces, interfaces, =
abstracts, closures, traits, parameter type hints, even classes are core =
features that users aren't forced to use.  Please tell me what makes =
them different.  It is an optional feature - just like all those I =
listed.  If others are using it, that's the point.  Can you walk into =
existing code that you must interface with today that has a type hinted =
parameter and decide not to use it?  No.  Why?  Because the =
company/developer who developed that solution made the decision that it =
was a feature they found useful.  What you're suggesting is that we =
design features around those who do not want to use it.=20

>=20
>> Don't forget that while return checks are runtime, interface
>> definition and implementations are compile time.
>=20
> 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.

So Java's bytecode, which requires a VM (interpreter), isn't comparable =
to PHP's "compile"?  Are you saying compile is only when code is =
converted into machine code?  Moving PHP code through a lexical =
analyzer, syntax parser, intermediate code generator/opcode isn't a form =
of compilation?  Considering the verification of interfaces is done =
during the syntax parser, in a file called zend_compile.c, before the =
code is actually executed, I'm pretty comfortable calling this =
transformation "compiled."


>=20
>> 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
>=20
> 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!

public function blah(SomeClass $class =3D null)
{
  if ($class)
  {
    // code here
  }
}

What I'm calling a "standard" is something already in the language.  If =
I had written this to allow "false" to be returned instead of null, the =
complaints would be much greater.  Why? Because we're used to the type =
hinting allowing that.

I want to make it clear that my goal with this RFC *isn't* to offer a =
compile time feature for the sake of having it.  Because PHP is =
interpreted and we have our on minds, we can make decisions such as the =
frequently used scenario you mentioned above.  If the general consensus =
is that you *must* return the type declared, then I'm game for it.  In =
fact, code execution would actually be faster.  But what will end up =
happening is this:

public array getArray()
{
   // Uh oh, I'll have to return an empty array
   return array();
}

$array_value =3D $obj->getArray();

if (!empty($array_value))

This is why I decided on the null option. =20



> --=20
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227