Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62246
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ez.no designates 216.32.180.31 as permitted sender)
Received-SPF: pass (mail102-va3: domain of ez.no designates 157.56.249.213 as permitted sender) client-ip=157.56.249.213; envelope-from=andre.romcke@ez.no; helo=AM2PRD0710HT002.eurprd07.prod.outlook.com ;.outlook.com ;
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Kris Craig <kris.craig@gmail.com>, Anthony Ferrara <ircmaxell@gmail.com>,
	Stan Vass <sv_forums@fmethod.com>, Stas Malyshev <smalyshev@sugarcrm.com>,
	Levi Morrison <morrison.levi@gmail.com>, "<internals@lists.php.net>"
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] Inline typecasting / typehinting for classes and
 interfaces
Thread-Index: AQHNefEF1xsAkzKcaEWsITcsxSxAV5dZU+IAgAAf7ICAABfkAIAA9+CxgABAbICAAGvmAIAABTkAgASUPIA=
Date: Sat, 18 Aug 2012 16:29:19 +0000
Message-ID: <7EC977AE-7678-42D6-98EC-7D21D81C3689@ez.no>
References: <A3182DBB9506422D9DCD5667BE48A0C4@pc>
 <CAFMT4NpOEFgDckOUdSx5x8h=H0a6FPubmyyPyvz-SMgxKgyhdw@mail.gmail.com>
 <CAAyV7nE-QTvXju3JayAaeLY1iDtUzWo6j+b66him11dzKAUKsw@mail.gmail.com>
 <502A86AA.2030203@sugarcrm.com> <E7BA2752DEBB42BF99C96CAECFBB2C80@pc>
 <CAAyV7nHVRZo8XCw77boMAxXtjrFxDGrCQPDAStpLSW5sA-6L5g@mail.gmail.com>
 <CAKOpQSyyMRAKMHi4QV55g8ddnwOojnTDSgGtbedOvfp4vw-tFw@mail.gmail.com>
 <CAF+90c_srmS-VTJFHk30r-17F_n=jV0xNpbm85neEyRJ4nBjiQ@mail.gmail.com>
In-Reply-To: <CAF+90c_srmS-VTJFHk30r-17F_n=jV0xNpbm85neEyRJ4nBjiQ@mail.gmail.com>
Accept-Language: nb-NO, de-DE, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <598BF898EF41034A91FFFB0F4021B8D7@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Inline typecasting / typehinting for classes and
 interfaces
From: andre.romcke@ez.no (=?iso-8859-1?Q?Andr=E9_R=F8mcke?=)

( resending with correct formatting, and missing context while at it, sorry=
 about that )

On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote:

> (...)
>=20
> Another aspect here is that there is no reasonable syntax for this
> feature, at least I can't think of one:
>=20
> * The syntax `$foo =3D (InterfaceName) $container->service` is
> completely out of question. It looks like a cast, but wouldn't
> actually do a cast.
> * Same is to be said about `InterfaceName $foo =3D
> $container->service`. This syntax implies that the $foo variable will
> always be of type InterfaceName, even if it is later reassigned. It's
> not a sensible syntax for a one time validation
> * The other three syntaxes that were mentioned were just as unclear.
> E.g. `$foo =3D $container->service as InterfaceName` again looks like a
> strange cast syntax and `$foo =3D $container->service is InterfaceName`
> looks like the assignment should evaluate to a boolean (i.e. `is` is
> some kind of `instanceof`).


good points
In addition, the root cause that triggered this proposal in the first place=
: serve container / object registry doc issue, is kind of moot, ref bellow.


>=20
> On the other hand, the current ways of accomplishing the same goal are
> well-established and easy to understand:
>=20
> * Using a docblock: /** @var $foo IntefaceName **/
> * Using an assertion: assert($foo instanceof InterfaceName).
>=20
> I think that the assertion is a rather concise and clear way to do
> this. It is much more obvious than some new and obscure `$foo =3D
> (InterfaceName $container->service)` syntax.



To expand on that, @Stan: If you make sure you configure your container to =
injection dependencies (and in case of lazy loading, inject factories* with=
 type hinting in doc) instead of passing the [dependency injection] contain=
er around as a registry, then you almost don't get this problem at all, and=
 you will avoid introducing container awareness/dependency in your architec=
ture.

Only place you will have this original problem though is in the code that g=
ets the first dependency of the execution, like in index.php for instance, =
but even then you can have Container interface for the most common root dep=
endencies.
In the cases that doesn't fit, you should plainly use the doc block referre=
d to by Nikita, it is already supported by IDE's and won't need additional =
3 years to get support.


* As alternatives to factories with or without container knowledge, there i=
s one alternative that some containers support:
  Proxy objects: container generates proxy objects whenever you want depend=
encies to be lazy loaded, they have container awareness, but this becomes 1=
00% transparent to your code, but it probably adds some overhead.=