Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82864
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <011801d04a07$83ab1c00$8b015400$@php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
Date: Mon, 16 Feb 2015 16:57:11 +0000
Message-ID: <CAPg3Xx+cUAZ3YqHzwgV175dcJteABsjM1S9YSF-q40ZZ0iDYrA@mail.gmail.com>
To: francois@php.net
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Jefferson Gonzalez <jgmdev@gmail.com>, 
	Rowan Collins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135e9a897cec3050f377cca
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: petercowburn@gmail.com (Peter Cowburn)

--001a1135e9a897cec3050f377cca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 16 February 2015 at 16:42, Fran=C3=A7ois Laupretre <francois@php.net> wr=
ote:

> Hi,
> >
> > De : Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
> >
> > The 0.1 RFC version was mentioned a lot as a good compromise by many
> > people
> > and had major support.
> > Maybe someone competent could pick it up, make necessary adjustments
> > that
> > where required and let people vote on it? Start with small steps - get
> the
> > weak type hints into the language first, see how it gets used and then =
we
> > can always add strict type hints if there is a need/desire to do that.
> >
> > That way we finally get type hints into the language, and those wanting
> the
> > strict variety have all the opportunities in the world to add them at a
> > later release with proper discussion and development time.
>
> That's what I am planning. If I write an RFC, it will be based on Andrea'=
s
> 0.1/0.2 version, and won't propose different modes.
>
> The problem is that the previous controversial RFC focused people on weak
> vs strict typing, while we should have explored other technical concerns.
> Here are the main ones I see :
>
> - the fact that the RFC supports single types only, like the previous
> 'return type' RFC. While it is easier to implement, it opens several issu=
es
> as multiply-typed arguments are an integral part of the PHP language
> (mostly completeness and compatibility with internal function hinting). I=
f
> we want to support multiple types the same way for internal and userspace
> functions, we must extend the ZPP layer to support it.
>
> - the mechanism to check for type hints on internal functions, while easy
> to implement, is not sufficient, as a lot of internal functions get a bar=
e
> zval from the parsing system and then convert it by themselves. With the
> proposed mechanism, there's no possible hinting on such argument, which
> will make the implementation different from the documentation. Even if th=
e
> check is done by the function body, it won't be done in a consistent way
> with type hinting checks and won't raise a similar error. As most cases a=
re
> related to multiply-typed args, the solution is in adding multiply-typed
> support to ZPP. Multiply-typed support needs to redefine scalar conversio=
n
> rules, to take care of the target type being a combination of single type=
s.
>
> - We need to define the appropriate extension to Reflection
> parameters/return type. That's not complex, but it takes time.
>
> - Other changes I'd like to propose are exposed in Bob Weinand's article,
> at https://gist.github.com/bwoebi/b4c5564388ecd004ba96. The article
> explains how restricting weak conversion possibilities would make strict
> typing almost useless. Changes include forbidding bool to int/float or
> '7years' to int. This cannot be left for future additions as BC breaks wi=
ll
> make it impossible. To remain consistent between userspace/internal
> functions, this must also be done at the ZPP level.
>
> - Using bare class names as type hints is a potential issue too, as it
> makes reserved keywords and class names share the same naming space. I
> think we should deprecate the use of class names as type hints in favor o=
f
> 'object(class-name)'. If we don't do that, every future addition of a typ=
e
> hint keyword will cause a BC break (and will be practically impossible).
>
> - Additional 'hybrid' types like 'numeric' and 'mixed' should be also
> provided.
>
> So, most features I have in mind are really 'now or never'.
>
> My main concern, anyway, is with March 15 announced feature freeze. If we
> need a vote by this date, it's impossible. And planning such BC for 7.1 i=
s
> probably unrealistic because of the huge syntax additions and BC breaks i=
t
> brings. So, if it's too late for an inclusion in 7.0, I think I'll give u=
p.
>
> So, could someone confirm what 'feature freeze' exactly means ?
>

Note that the accepted timeline for PHP 7 [1] states that we will have
three months to "Finalize implementation & testing of new features", after
the March deadline.  That should give us some time to tie down the actual
implementation side of things. Apart from that, it's more a matter of
getting an RFC drafted, discussed, voted on, before the March deadline.

I, for one, wouldn't mind the vote taking a wee while longer (say, a week
or two) if it means we can get this feature added.


>
> Regards
>
> Fran=C3=A7ois
>
>
>
>
>
>
>
>
>  The main issues are completeness (we can give hints for some cases, but
> not for others) and, more important, the compatibility with internal
> functions. As Andrea herself agreed, her mechanism for type hinting on
> internal functions is not sufficient. Just using the ZPP macros, as they
> exist today, won't work as a lot of internal functions get a bare zval an=
d
> then convert it by themselves. So, in this case, we would check nothing.
> So, an argument described as 'string|array' in the documentation, wouldn'=
t
> produce the same sort of error when sent an object, than its friend,
> described as 'string'. This is not consistent and will open a lot of side
> effects if it is left out of the type hint layer.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1135e9a897cec3050f377cca--