Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74113
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender)
Message-ID: <536D50B0.408@sugarcrm.com>
Date: Fri, 09 May 2014 15:03:28 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Josh Watzman <jwatzman@fb.com>, Levi Morrison <levim@php.net>
CC: internals <internals@lists.php.net>
References: <CAFMT4Nrie2zAtVxcxg_xsDWs7EAa5fxk+d8aBH1=sZ=s_KFY2g@mail.gmail.com> <90B71511-4FB4-4916-9AC0-E3DD0D328C37@fb.com> <536D46C5.7040302@sugarcrm.com> <FCC3EA09-D690-4260-91DD-C361CF839FBB@fb.com>
In-Reply-To: <FCC3EA09-D690-4260-91DD-C361CF839FBB@fb.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Our view is that this code was *already* wrong. The type annotations
> don't make it more or less wrong. What they do let you do is enforce,

Of course it is wrong. The whole point of having strict typing is to
catch wrong code. If everybody would write only right code, we wouldn't
need any type checks - everything would be ok anyway (not correct for
some compiled languages as there types also tell the compiler how to
convert values to bits, but true for languages like PHP).

> once the annotation is in place, that it's correct moving forward for
> the places that are annotated. (And if you want to go fix up and

The whole point is that it won't be correct. In your model, when you use
typed function, essentially you know nothing about its return type, as
somebody could have overridden it with function returning anything. So
the only thing typing is useful for in your model is to document our
wishes about types. We already have that with @returns.

> your entire hierarchy all at once -- gradual conversion of existing
> code was an important feature when we were adding the Hack type
> system onto PHP.

My opinion is that we should not add features that do not make sense
conceptually. I have my issues with strict typing in php in general,
which I voiced at length here on the list already, but at least I can
see some internal logic in the concept, even though I still think it's
not the best fit for dynamic languages (neither Python nor Ruby nor
Javascript, to take three most popular ones, have it). But at least,
repeating, internal logic of knowing the variable type past the check is
there. What you are proposing is essentially documentation-only - you
can never know when you call a method what you are actually getting,
unless you explicitly check the object type for exact match (which
current strict typing syntax doesn't even allow). This is lacking even
internal logic, so I don't see how it makes sense to have such concept
in PHP.

> typechecker, or even by a human. The type "static" tends to be what
> you want. But this isn't a huge deal -- "self" as proposed isn't
> *wrong*.

That depends on the method - I can see cases for both. Consider this:
class Toy {
static function ToyFactory($toy_class): self {
  return new $toy_class;
}}
The one with static would have different semantics than the one with self.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227