Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74108
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <536D46C5.7040302@sugarcrm.com>
Date: Fri, 09 May 2014 14:21:09 -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>
In-Reply-To: <90B71511-4FB4-4916-9AC0-E3DD0D328C37@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!

> everything. This means that, not only can a superclass omit an
> annotation that a subclass specifies, but a *subclass* can omit an
> annotation that the superclass specifies. While this isn't the most

I'm not sure it is a good idea. This means having this code:
class FooGetter {
  function getFoo(): Foo { return new Foo(); }
}

I can extend it as:
class TwoFaceFooGetter extends FooGetter {
  function getFoo() { return rand()%2?new Bar():new Foo(); }
}

and every function getting FooGetter and expecting getFoo() to return
Foo is now broken since instead it could just get Bar(). Since the type
return specification is meant, as far as I understand, exactly to avoid
cases like that, I don't see it as a good idea.

> principled methodology from a hardcore type system perspective, we
> believe it is very pragmatic and interoperates well with the
> dynamically typed world of PHP. It's been extremely important to us

I don't see how having strict typing and then making exceptions for
"dynamic typed world of PHP" makes much sense. If we want dynamic typed
world, we should do what Ruby, Python, Javascript and others do. If we
want to go to strict typing direction instead, we should provide
guarantees that strict typing is for. Having strict typing without
guarantees makes very little sense to me.

> There is always an easy escape hatch. If you require subclasses to

The point of strict typing is not having escape hatches. If you can just
put anything into typing system and say "shut up and accept it", then
you have no guarantees that any value is of any known type. And the the
question is - why bother with strict typing at all? What advantage it
gives if it's not guarantees that values have known types?

> discussion. What is the reason for "self"? The Hack type system calls
> it "this", which I admit is a little confusing since it is the type

"this" is not a type in PHP. "self" is, which is the type of the class
it is mentioned in.

> of more things than just the literal variable "$this" ("new static"
> for example is also of type "this"). But the type "static" is much

"new static" in PHP is not of a known type statically. Dynamically, it
is of a type that the method was called with, which is signified,
somewhat confusingly, by the keyword "static" even though it is actually
not static as dynamic (yes, I know, welcome to the wonderful world of
keyword reuse).

> more consistent with the existing LSB language, i.e., "new static"..
> So is there any reason to call it "self" over "static" or "this"?

"self" and "static" are two distinct type keywords. "this" is not a type
keyword at all, is there a need for yet another type keyword? I don't
think so.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227