Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77753
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.220.196 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <78BE550F-8867-4DCD-99E1-B2EFF114AE3A@ajf.me>
References: <CAFKaYMoGCa55yhRmoZTCQD2bogcOy0wZVCfYYaq1fMC8saoNNg@mail.gmail.com>
	<78BE550F-8867-4DCD-99E1-B2EFF114AE3A@ajf.me>
Date: Fri, 3 Oct 2014 01:13:41 +0100
Message-ID: <CAFKaYMpSTD9gam=w+nN+EO-24QaxK08B95__V7LSCW+8bhBDhg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=bcaec54860d4024a640504799b7d
Subject: Re: [PHP-DEV] Concept: Custom Type Hinting
From: codekestrel@googlemail.com (Dominic Grostate)

--bcaec54860d4024a640504799b7d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3 October 2014 00:49, Andrea Faulds <ajf@ajf.me> wrote:

> Functions in PHP cannot be autoloaded, so this would be quite inconvenien=
t
> to use. Will people bother adding an include to every file merely to use
> typehints? Or are typehints classes, in which case, why not simply define
> them as a class rather than adding a new keyword? Or are they are new kin=
d
> of autoloaded thing?
>
> As Johannes mentioned, this would require a function call every time an
> argument is passed. Unlike, say, auto boxing, once validated, you will
> still need to validate it again for each call. The performance impact isn=
=E2=80=99t
> so good.
>
> How does this handle references, and how does it handle null? How is
> inheritance/interface compatibility dealt with?
>

They would be treated with the same respect as classes, in the same sense
as traits are.  Therefore the autoloading would apply to them, as would
namespaces.
Using actually classes was my first though.  I was thinking about a special
interface like "TypeHint" which would invoke special treatment when used in
type hinting.
However I was getting caught up in the semantics of what contract the class
should have with the interface.

Regarding the additional function calls, I don't know.  If the performance
hit is due to calling the user defined handler, then I would justify it by
arguing that a similar hit would be suffered from the necessity to use a
strict type to begin with, when the user validates the values in the method
which requires it.  If however you are referring to an engine function call
made to determine if the type hint is indeed a special type hint or a
class, then yes I would agree.

For references I proposed that the value parsed to the handler would be a
reference of the actual argument, so any changes made in the handler would
propagate to the previous scope if the original argument is intended to
*be* a reference.
For inheritance and compatibility, I hadn't thought about, but considering
a sub class or implementer cannot break the compatibility of its
parent/interface,  the same rules would apply.

Thanks,
Dominic

--bcaec54860d4024a640504799b7d--