Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82865
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.179 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 19:06:01 +0200
Message-ID: <CAL0xaBEuAURjV802Cq-__yR8uugFaqxGUcK0bmug2rkOEHwS-Q@mail.gmail.com>
To: francois@php.net
Cc: Jefferson Gonzalez <jgmdev@gmail.com>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11409f08fd6480050f379a8c
Subject: Re: Reviving scalar type hints
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11409f08fd6480050f379a8c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-02-16 18:42 GMT+02:00 Fran=C3=A7ois Laupretre <francois@php.net>:

> 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 ?
>
> 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.
>
>
Sounds quite reasonable and level headed. I'm gonna contact you off-list to
assist in any way I can, i'll be damned if RFC fails 4th time...

--001a11409f08fd6480050f379a8c--