Hi Dmitry,
Dmitry Stogov wrote:
I also don't like reserving new class names or limiting their use.
The message above looks clear and it shouldn't be a big problem to
implement the fix.
This fix shouldn't change anything except error message, so it'll make
minimal risk for 7.0 release process.
Hi Adam,
Adam Harvey wrote:
(Sorry Andrea, I'm picking on your e-mail because it's easiest, but
it's a general response to the thread.)
Ah, don't worry about it.
I agree that we should do something, but I think we should alias.
We allow both "int" and "integer" in settype() and we allow it
On Tue, Oct 13, 2015 at 6:40 PM, Anthony Ferrara
wrote:
> All,
>
> On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins
> wrote:
> > Andrea Faulds wrote on 13/10/2015 12:00:
> >>
> >> Hi Michael,
> >>
> >> Michael Wallner wrote:
> >>>
> >>> On 12/10/15 21:23, Andrea Faulds wrote:
>
> Even if
(Sorry Andrea, I'm picking on your e-mail because it's easiest, but
it's a general response to the thread.)
On 13 October 2015 at 06:32, Andrea Faulds wrote:
> e.g.
>
> $ ./sapi/cli/php -r 'function foo(): long {}'
>
> Fatal error: 'long' is not a valid type hint, use 'int' instead in
> C
On 10/13/15, 10:59 AM, "Anthony Ferrara" wrote:
>
>Overall, I don't think this should be ported back to 5.x
>
>First off, it's pretty late in both 5.5 and 5.6 lifetimes (5.6 is
>already up to .14).
>
>Introducing a feature this late would basically make it useless to the
>vast majority of users of
All,
On Tue, Oct 13, 2015 at 9:56 AM, Rowan Collins wrote:
> Andrea Faulds wrote on 13/10/2015 12:00:
>>
>> Hi Michael,
>>
>> Michael Wallner wrote:
>>>
>>> On 12/10/15 21:23, Andrea Faulds wrote:
Even if we can't reserve the names, I hope we can do the two other
suggestions in tim
Tom,
On Tue, Oct 13, 2015 at 10:17 AM, Tom Worster wrote:
> On 10/12/15 10:53 PM, Larry Garfield wrote:
>>
>> On 10/12/2015 07:29 PM, Tom Worster wrote:
>>>
>>> Could we regard random_bytes() as a security patch rather than a new
>>> feature and therefore port it to PHP 5?
>>>
>>> Error handling
Tom Worster wrote on 13/10/2015 01:29:
Could we regard random_bytes() as a security patch rather than a new
feature and therefore port it to PHP 5?
Whether or not it's good for security, it's still a feature - you still
have to code your application to depend on this feature being present,
or
On 10/12/15 10:53 PM, Larry Garfield wrote:
On 10/12/2015 07:29 PM, Tom Worster wrote:
Could we regard random_bytes() as a security patch rather than a new
feature and therefore port it to PHP 5?
Error handling would have to change but that should be feasible. Iirc,
earlier commits of random_by
Hi Paul,
Paul Dragoonis wrote:
On Mon, Oct 12, 2015 at 8:23 PM, Andrea Faulds wrote:
Hi Andrea,
Can you go ahead and make a branch/PR to add these type aliases in? There's
no right or wrong answer to 'int' versus 'integer', so allowing devs to
continue to use either will be welcoming.
I've
Results for project php-src-nightly, build date 2015-10-13 14:15:04+03:00
commit: dcced66739b08c422c1ad57715804e948dea8f91
revision_date: 2015-10-13 11:49:13+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
Andrea Faulds wrote on 13/10/2015 12:00:
Hi Michael,
Michael Wallner wrote:
On 12/10/15 21:23, Andrea Faulds wrote:
Even if we can't reserve the names, I hope we can do the two other
suggestions in time for release.
Additionally, we could say "instance of class ...".
We could do that, tho
Hi Derick,
Derick Rethans wrote:
On Mon, 12 Oct 2015, Andrea Faulds wrote:
you'll get the following error:
Fatal error: Uncaught TypeError: Return value of foo() must be an instance
of integer, integer returned
you'd get this:
Fatal error: Uncaught TypeError: Return value of f
Hi,
Peter Cowburn wrote:
On 13 October 2015 at 11:59, Andrea Faulds wrote:
Hi Peter,
Peter Cowburn wrote:
The manual uses them almost exclusively,
Not for type signatures it doesn't. It usually uses "int" and "bool".
I said "almost" for a reason. More clearly, we use the long names
Thanks all for the responses!
I agree that it isnt a core functionallity, but it would be nice to have it
always there to use.
thank you for thinking its a good idea guys!
2015-10-10 17:22 GMT-03:00 Johannes Schlüter :
> On Thu, 2015-10-08 at 12:05 -0300, Mattias Gonzalez wrote:
> > I wanted t
On 13 October 2015 at 11:59, Andrea Faulds wrote:
> Hi Peter,
>
> Peter Cowburn wrote:
>
>> I would much rather we use the full names for these types across the
>> board.
>>
>
> I would mostly agree with you. Using the full English names whenever we're
> writing English, not code, makes sense. Bu
On Tue, 13 Oct 2015, Andrea Faulds wrote:
> Peter Cowburn wrote:
>
> > Failing that, at least making them available as aliases is a good
> > thing in my book. I never understood the reluctance to make use of
> > all existing names when the type declarations discussions were going
> > on. Fact
2015-10-13 13:08 GMT+02:00 Derick Rethans :
> What about double vs float? Another common combination.
(or "real" -- just to compliment the typecast)
=P
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
On Mon, 12 Oct 2015, Andrea Faulds wrote:
> you'll get the following error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an instance
> of integer, integer returned
> you'd get this:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an instance
>
Hi Michael,
Michael Wallner wrote:
On 12/10/15 21:23, Andrea Faulds wrote:
Even if we can't reserve the names, I hope we can do the two other
suggestions in time for release.
Additionally, we could say "instance of class ...".
We could do that, though it's already 'instance of'. Not sure o
Hi Peter,
Peter Cowburn wrote:
I would much rather we use the full names for these types across the board.
I would mostly agree with you. Using the full English names whenever
we're writing English, not code, makes sense. But we usually use
int/float/etc. in code, like other languages do, an
On 12 October 2015 at 20:23, Andrea Faulds wrote:
> Hi,
>
> As PHP 7 currently is, if you write this:
>
> public function foo(): integer {
> return 12;
> }
> $bar = foo();
>
> you'll get the following error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must b
On 12/10/15 21:23, Andrea Faulds wrote:
> Hi,
>
> As PHP 7 currently is, if you write this:
>
> public function foo(): integer {
> return 12;
> }
> $bar = foo();
>
> you'll get the following error:
>
> Fatal error: Uncaught TypeError: Return value of foo() must be an
> i
On Mon, Oct 12, 2015 at 8:23 PM, Andrea Faulds wrote:
> Hi,
>
> As PHP 7 currently is, if you write this:
>
> public function foo(): integer {
> return 12;
> }
> $bar = foo();
>
> you'll get the following error:
>
> Fatal error: Uncaught TypeError: Return value of foo() mu
Hi,
> -Original Message-
> From: Xinchen Hui [mailto:larue...@php.net]
> Sent: Tuesday, October 13, 2015 4:23 AM
> To: Anatol Belski
> Cc: Nikita Popov ; Dmitry Stogov ;
> PHP internals
> Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by
> ReflectionFunctionAbstrac
25 matches
Mail list logo
