Hello Sebastian,
On 01.01.15 09:28, Sebastian Bergmann wrote:
Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
Parameter type hints for PHP’s scalar types
Please use the term type declaration for arguments (or type
declaration for parameters) instead of type hints. If it's used
then it's
Thanks for analizing.
did you say 8.5 more instructions?
in my test I saw less.
It's really an intermedie step, and we probably will check if other
optimizations are reaaly benefitable before committing this. But yes, this
patch doesn't make any degradation, except for slight increase of memory
Hi François,
this is not a proposal yet, this is just an initial request to the most
experinced PHP developers to think about possible consequnces.
Thanks. Dmitry.
On Dec 31, 2014 9:50 PM, François Laupretre franc...@tekwire.net wrote:
De : Dmitry Stogov [mailto:dmi...@zend.com]
Please
Hey Zeev,
On 1 Jan 2015, at 12:41, Zeev Suraski z...@zend.com wrote:
I like this draft too, and that's a first after countless proposals over the
last decade - so kudos! :)
Glad to hear that.
My main feedback here are the discrepancies between this RFC's casting rules
and PHP's current
On Wed, Dec 31, 2014 at 11:19 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Please take a look into the patch
https://github.com/php/php-src/pull/970/files
This real changes are in zend_types.h, the rest is renaming that in most
cases makes code cleaner.
zend_array didn't change its
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, December 31, 2014 10:28 PM
To: PHP Internals
Subject: [PHP-DEV] [RFC] Scalar Type Hints
Good evening,
Parameter type hints for PHP’s scalar types are a long-requested feature
for
PHP. Today I am
Hi Maxime,
On 1 Jan 2015, at 13:29, Maxime Veber nek@gmail.com wrote:
I was expected an RFC like this in PHP for a while. I'm happy somebody made
one, thanks.
Glad to hear that.
But something hit me in that. even if you can't give an objet, you can give
any scalar type that will be
Hey Sebastian,
On 1 Jan 2015, at 08:28, Sebastian Bergmann sebast...@php.net wrote:
Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
Parameter type hints for PHP’s scalar types
Please use the term type declaration for arguments (or type
declaration for parameters) instead of type hints. If
The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
create serious impediments. So I wonder if we couldn't have both (strict
and coercive
Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
Parameter type hints for PHP’s scalar types
Please use the term type declaration for arguments (or type
declaration for parameters) instead of type hints. If it's used
then it's not a hint.
--
PHP Internals - PHP Runtime Development Mailing
Hello,
I was expected an RFC like this in PHP for a while. I'm happy somebody made
one, thanks.
But something hit me in that. even if you can't give an objet, you can give
any scalar type that will be cast.
I'm not sure this behavior is very relevant.
Actually if I ask for a string, why the
Hi Markus,
On 1 Jan 2015, at 11:09, Markus Fischer mar...@fischer.name wrote:
1. the naming of the RFC thus the intent is confusing
What it really does is it tries its best to convert, e.g. the RFC reads
as it tries to work like this:
function foo(int $bar) {
$bar = (int)$bar;
}
Hi Markus,
On 1 Jan 2015, at 15:58, Markus Fischer mar...@fischer.name wrote:
On 01.01.15 16:19, Andrea Faulds wrote:
I think it’d be weird to have different syntaxes for scalars and
non-scalars. We already use the syntax the RFC proposes in the PHP manual,
and I don’t think anyone’s
Hi Nikita,
On Jan 1, 2015 5:23 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Dec 31, 2014 at 11:19 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Please take a look into the patch
https://github.com/php/php-src/pull/970/files
This real changes are in zend_types.h, the rest is
Woow. The compromise proposed by Marcio looks awesome to me :) .
Andrea, I can understand that in the PHP logic, but IMO if the RFC does not
avoid people that use code like I present before i don't think it's
completely relevant.
I mean, if people still use old tricks because the type hinting
On Thu, Jan 1, 2015 at 4:59 PM, Marcio Almada marcio.w...@gmail.com wrote:
The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you DON'T WANT TYPE CASTING AT ALL. This new feature would
create
thanks for the rfc! Currently we allow:
function test(Array $o){}
test([]);
function test2(array $o){}
test2([]);
So I propose to allow also uppercase type names:
ublic function __construct(String $name, Int $age, Float $cuteness, Bool $evil)
{
Regards
Thomas
Andrea Faulds wrote on 31.12.2014
genius and simple syntax!
int $a === assertInt($a)
(int)$a === (int)$a
2015-01-01 18:59 GMT+03:00 Marcio Almada marcio.w...@gmail.com:
The battle between strict type declarations vs coercive has been here for a
while. My problem with coercion in detriment of strictness is
that sometimes you
On 1 January 2015 at 17:44, Thomas Bley ma...@thomasbley.de wrote:
I think it is no problem to add strict parameter type hints with another
rfc (if this rfc gets accepted), e.g. function foobar(string! $str, int!
$str){} or any other syntax.
The problem is that the current proposed
Hi Thomas,
On 1 Jan 2015, at 16:54, Thomas Bley ma...@thomasbley.de wrote:
thanks for the rfc! Currently we allow:
function test(Array $o){}
test([]);
function test2(array $o){}
test2([]);
So I propose to allow also uppercase type names:
ublic function __construct(String $name, Int
On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
Parameter type hints for PHP’s scalar types are a long-requested feature
for PHP. Today I am proposing an RFC which is a new attempt to add them to
the language. It is my hope that we can finally get this done
Hi,
On Thu, January 1, 2015 13:30, Dmitry Stogov wrote:
Thanks for analizing.
did you say 8.5 more instructions? in my test I saw less.
It's really an intermedie step, and we probably will check if other
optimizations are reaaly benefitable before committing this. But yes, this
patch
for the record this was proposed (as an idea) previously with the exact
same syntax(the earlies mention I could find in my mailbox was from
Derick from 2009: http://comments.gmane.org/gmane.comp.php.devel/57653 but
I remember seeing it every time when this
discussion happens).
If somebody is
Hey Levi,
On 1 Jan 2015, at 17:19, Levi Morrison le...@php.net wrote:
On Thu, Jan 1, 2015 at 9:44 AM, Thomas Bley ma...@thomasbley.de wrote:
I think it is no problem to add strict parameter type hints with another rfc
(if this rfc gets accepted), e.g. function foobar(string! $str, int!
The problem is that the current proposed hints/casts are deviating from the
type-hints that we are used to
I don't think type hints we currently have are different. The only difference
we have is that there is no automatic casting for objects/arrays to scalars and
scalars to objects/arrays (I
Hey Marco,
On 1 Jan 2015, at 16:56, Marco Pivetta ocram...@gmail.com wrote:
The problem is that the current proposed hints/casts are deviating from the
type-hints that we are used to, therefore this particular feature should
(eventually) have an alternate syntax, whereas the strict hints
when looking into phpdoc, e.g. http://de.php.net/substr we have string and int
everywhere in function definitions, do you want to change the whole
documentation?
Regards
Thomas
Levi Morrison wrote on 01.01.2015 18:19:
On Thu, Jan 1, 2015 at 9:44 AM, Thomas Bley ma...@thomasbley.de wrote:
I
On 1 January 2015 at 14:05, Nikita Popov nikita@gmail.com wrote:
While in favor of introducing scalar type annotations, I'm against this
proposal in particular. I've held a different position in the past, but by
now I'm thoroughly convinced that if we introduce scalar type declarations,
On Thu, Jan 1, 2015 at 9:44 AM, Thomas Bley ma...@thomasbley.de wrote:
I think it is no problem to add strict parameter type hints with another rfc
(if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){}
or any other syntax.
I would rather have it the other way around.
Hi!
Please use the term type declaration for arguments (or type
declaration for parameters) instead of type hints. If it's used
then it's not a hint.
Thank you! I was just going to post this. We've made this mistake once,
but we don't have to perpetuate it. It's no hinting, it's type
On Fri, Jan 2, 2015 at 12:58 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Apart from being consistent with the existing behavior of type
declarations
We have no existing behavior of scalar type declarations except for
hidden ones in internal functions and object types behave in
Hey Nikita,
On 1 Jan 2015, at 14:05, Nikita Popov nikita@gmail.com wrote:
While in favor of introducing scalar type annotations, I'm against this
proposal in particular. I've held a different position in the past, but by
now I'm thoroughly convinced that if we introduce scalar type
Stanislav Malyshev wrote on 02.01.2015 01:57:
Hi!
ZF2 completely broke compatibility with ZF1 users, so I think this is
a bad example.
We're talking about different things here. PHP is an universal platform
and PHP 7 would be offered as upgrade to all PHP users - running ZF1,
ZF2,
Hi!
ZF2 completely broke compatibility with ZF1 users, so I think this is
a bad example.
We're talking about different things here. PHP is an universal platform
and PHP 7 would be offered as upgrade to all PHP users - running ZF1,
ZF2, Symphony, Drupal, anything. If there would be a sizeable
On Jan 2, 2015 12:24 PM, Sara Golemon poll...@php.net wrote:
I realize that ZE3 is not ZE2, but I always saw the ZEND_ENGINE_2
define as more of a At least ZE2 so that code of the form:
#ifdef ZEND_ENGINE_2
newAPI();
#else /* ZE1 */
oldAPI();
#endif
Would continue making sense
I realize that ZE3 is not ZE2, but I always saw the ZEND_ENGINE_2
define as more of a At least ZE2 so that code of the form:
#ifdef ZEND_ENGINE_2
newAPI();
#else /* ZE1 */
oldAPI();
#endif
Would continue making sense (modulo newNewAPI() in ZE3, of course).
Was the ZEND_ENGINE_2 define
I don't necessarily have any more insight to provide than has already
been done, but I do want to chime in and say that I personally favor
strict types as Nikita Popov has been advocating.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think it is no problem to add strict parameter type hints with another rfc
(if this rfc gets accepted), e.g. function foobar(string! $str, int! $str){} or
any other syntax.
Regards
Thomas
Nikita Popov wrote on 01.01.2015 15:05:
On Wed, Dec 31, 2014 at 9:27 PM, Andrea Faulds a...@ajf.me
Hello Andrea,
On 01.01.15 16:19, Andrea Faulds wrote:
I think it’d be weird to have different syntaxes for scalars and non-scalars.
We already use the syntax the RFC proposes in the PHP manual, and I don’t
think anyone’s confused by it.
I didn't meant to stay there's something wrong with
Hi!
Apart from being consistent with the existing behavior of type declarations
We have no existing behavior of scalar type declarations except for
hidden ones in internal functions and object types behave in PHP
completely differently from scalars, so there's no place for
consistency claim
ZF2 completely broke compatibility with ZF1 users, so I think this is a bad
example.
Regards
Thomas
Stanislav Malyshev wrote on 02.01.2015 01:15:
Hi!
Yeah, it’s a problem. I think some breakage here is inevitable,
unfortunately. Some of the classes with these names are stand-ins for
Hi Stas,
On 2 Jan 2015, at 00:15, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
Yeah, it’s a problem. I think some breakage here is inevitable,
unfortunately. Some of the classes with these names are stand-ins for
scalar type hints, so that code can “just” migrate to using actual
On 01/01/2015 10:35 AM, Andrea Faulds wrote:
Now, going on step back here (talking about me), I'm speaking up because
my needs are developer are different (mostly speaking about backend
code, interfaces, libraries, frameworks) but OTOH I'm not a big known
open source framework developer either
Hi!
Yeah, it’s a problem. I think some breakage here is inevitable,
unfortunately. Some of the classes with these names are stand-ins for
scalar type hints, so that code can “just” migrate to using actual
hints. But this doesn’t apply to all of them.
Breaking ZF2 and all software built on it
On 1 Jan 2015, at 23:58, Stanislav Malyshev smalys...@gmail.com wrote:
ability to check correct usage with tooling. I'd also like to point out
that Hack uses a strict type scheme and it seems to work well there (though
Java uses strict typing too. And Perl has no typing whatsoever. So
Hi!
If they were case-sensitive, this would be inconsistent with other type names
like array and callable.
Of course, I mean making all these hints case-sensitive. I have never
seen code using uppercase Callable or Array, though I imagine it might
happen. Github's search is case-insensitive
Hi!
The problem is that the current proposed hints/casts are deviating from the
type-hints that we are used to, therefore this particular feature should
Let's check the manual we're used to.
http://php.net/manual/en/function.substr.php
string substr ( string $string , int $start [, int
Hi!
I'm referring to consistency with existing non-scalar type declarations
supported by userland functions. They are strict.
There's no choice here as object types are not convertable in principle
(well, not unless we do convert ctors like C++ but IMHO that would be a
bit crazy). You can't
48 matches
Mail list logo
