Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62172
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 209.85.215.170 cause and error)
Message-ID: <BA80B4FBBBB24E61AE6A6B732EE3EC99@pc>
To: "Nikita Popov" <nikita.ppv@gmail.com>
Cc: "Stas Malyshev" <smalyshev@sugarcrm.com>,
	"Anthony Ferrara" <ircmaxell@gmail.com>,
	"Levi Morrison" <morrison.levi@gmail.com>,
	<internals@lists.php.net>
References: <A3182DBB9506422D9DCD5667BE48A0C4@pc><CAFMT4NpOEFgDckOUdSx5x8h=H0a6FPubmyyPyvz-SMgxKgyhdw@mail.gmail.com><CAAyV7nE-QTvXju3JayAaeLY1iDtUzWo6j+b66him11dzKAUKsw@mail.gmail.com><502A86AA.2030203@sugarcrm.com><F5E021D8A355497C80E974B04320D375@pc> <CAF+90c_12NjBK6UvHagEBbh73_vAR2n2Bz58YjUond0EEnyDTQ@mail.gmail.com>
Date: Wed, 15 Aug 2012 11:39:06 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
From: sv_forums@fmethod.com ("Stan Vass")

> On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass <sv_forums@fmethod.com> wrote:
>> I'd like to also ask people to read what the intended effect of the 
>> proposal
>> is instead of going into abstract discussions about how casting one class 
>> to
>> another doesn't make sense (this is not what's being proposed).
>
> I think you confused everyone by a) having "typecasting" in the title
> and b) starting with the (Foo) casting syntax (so everyone assumed
> that you indeed want some kind of class casts, whatever that may be).

I had "typecasting / typehinting" in the title, and I'd like to remind 
everyone again that in dynamically typed languages class casts are often 
implemented as a basic validation operation, consistent with what I 
proposed.

> Regarding the actual proposal, could you maybe clarify the use-cases
> for this? I can see that it could be useful in principle, but your
> actually named use cases confuse me somewhat. In particular, I don't
> see how this would help dependency injection containers. I can see
> that it helps service locators and registries, but both of those are
> considered antipatterns, so there is no reason to add additional
> language features for them. DICs are only used to inject top-level
> dependencies, so in that case types should be fairly well covered by
> parameter type hints.

Two use cases apart from registries: PHP has no typed iteration and arrays, 
so you the only way to guarantee (and the IDE to know) the type of a 
variable in these cases is a hint:

Foo $bar = $array[1];
foreach ($array as Foo $item) { ... }

Automatically this applies to everything that uses ArrayAccess as a 
shorthand too, and properties of anonymous objects (stdClass).

The current alternative is peppering code with pseudo-PHPDoc inline hints, 
and instanceof assertions which truly is a facility the language core should 
provide, instead of us emulating it.

Stan