I have updated the section on Reflection to explain some of the design
decisions: https://wiki.php.net/rfc/returntypehinting#reflection;
hopefully that will help you and others to understand the rationale.
Please let me know if you have follow-up questions.
--
PHP Internals - PHP Runtime
Markus
On 19 October 2014 20:31, Markus Fischer mar...@fischer.name wrote:
On 16.10.14 06:39, Levi Morrison wrote:
- The design and accompanying section of reflection[3] has been
rewritten entirely.
[3]: https://wiki.php.net/rfc/returntypehinting#reflection
I've some comments about the
On 16.10.14 06:39, Levi Morrison wrote:
- The design and accompanying section of reflection[3] has been
rewritten entirely.
[3]: https://wiki.php.net/rfc/returntypehinting#reflection
I've some comments about the Reflection API addition/changes:
1. Note that getReturnType will always
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
+1
The implementation has some minor issues.
Levi, if you won't object, I would like to play with implementation a bit,
right before commit (if it accepted).
Dmitry
On 16 October 2014 08:44, Dmitry Stogov dmi...@zend.com wrote:
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
May I enquire what it misses out according to your ideal desired
feature set? Just so that
On Thu, Oct 16, 2014 at 6:39 AM, Levi Morrison levi_morri...@byu.edu
wrote:
Dear Internals,
I finally have a working implementation for return types RFC[1] built
on top of master. There are a few notes in the PR[2] about the
implementation. I invite you all to review the PR and provide
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
methods[4].
Perhaps, along the same lines, we could error if you use a nonsensical type
hint for magic methods?
For example, allow this:
class
Hi Chris,
I meant scalar type hinting, nullable type hinting, may be even mixed type
hinting...
But, lets go by small steps to get all this finally accepted.
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 1:35 PM, Chris Wright c...@daverandom.com wrote:
Dmitry
On 16 October 2014 08:44, Dmitry
I think the patch already does it (may be not for all magic methods).
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 2:58 PM, Andrea Faulds a...@ajf.me wrote:
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
On 10/16/2014 09:44 AM, Dmitry Stogov wrote:
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
+1
I second that emotion; +1.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I very much like this — though I would say it was dependent on the nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand and
respect the limitations on the RFC.
However, one thing that I do think is missing, is the
On Thu, 16 Oct 2014 18:39:06 +0400, Davey Shafik da...@php.net wrote:
I very much like this — though I would say it was dependent on the
nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand
and
respect the
Hi Levi,
This RFC is pretty consistent, small and focused on a specific part of the
overall previously desired support.
I do think many more subsequent RFCs would come up after this one to expand
return typehint support, but as it stands right now is extremely good. Any
further inclusion would
Dear Internals,
I finally have a working implementation for return types RFC[1] built
on top of master. There are a few notes in the PR[2] about the
implementation. I invite you all to review the PR and provide
feedback.
This means that I will soon move the return types RFC to voting phase.
If
14 matches
Mail list logo
