Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62146
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NpOEFgDckOUdSx5x8h=H0a6FPubmyyPyvz-SMgxKgyhdw@mail.gmail.com>
References: <A3182DBB9506422D9DCD5667BE48A0C4@pc>
	<CAFMT4NpOEFgDckOUdSx5x8h=H0a6FPubmyyPyvz-SMgxKgyhdw@mail.gmail.com>
Date: Tue, 14 Aug 2012 11:45:35 -0400
Message-ID: <CAAyV7nE-QTvXju3JayAaeLY1iDtUzWo6j+b66him11dzKAUKsw@mail.gmail.com>
To: Levi Morrison <morrison.levi@gmail.com>
Cc: Stan Vass <sv_forums@fmethod.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d041827527d1e3604c73bb3cb
Subject: Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
From: ircmaxell@gmail.com (Anthony Ferrara)

--f46d041827527d1e3604c73bb3cb
Content-Type: text/plain; charset=ISO-8859-1

Levi,

On Tue, Aug 14, 2012 at 9:51 AM, Levi Morrison <morrison.levi@gmail.com>wrote:

> On Tue, Aug 14, 2012 at 1:46 AM, Stan Vass <sv_forums@fmethod.com> wrote:
> > I've felt the need for this for some time.
> >
> > Proposed syntax:
> > -------------------------
> >
> > $x = (InterfaceName) $container->service;
>
> I'm against this.  Let's be honest, how different is this that an
> optionally static type?
>
> InterfaceName $x = $container->service;
>
> To be clear, I WANT optionally static typing. For the most part,
> type-hinting in class methods solves the static typing needs, but if
> we were able to declare a class member to be a certain type that would
> be another significant improvement.  I have a proposal in the works,
> but I don't want to hijack your thread.
>
> To sum up: I think we need something LIKE what you are proposing, but
> I'm against this particular proposal.
>

I agree with you. The one case where this syntax may be very useful is if
we want to implement class casting. So introduce a pair of magic methods

public function __castToClass($class) {
}

public static function __castFromScalar($scalar) {
}

Then,

$foo = (A) $objectExtendingFromA; // No-op
$foo = (A) $objectNotFromA; // Calls $objectNotFromA->__castToClass('A'),
and if it returns something that matches A, good, if not fail
$foo = (A) 1; // Calls A::__castFromScalar(1);

Now, note that it would only work on class names, as doing it on interfaces
would only work in the objectNotFromA case (and even then, it would be
weird).

Now, I'm just saying that this is the only way I'd want to see something
like this. The use cases for it are there, but extremely narrow and likely
better solved with other mechanisms. So I'm not completely sure I like the
concept as a whole, but just throwing it out there...

Anthony

--f46d041827527d1e3604c73bb3cb--