Stanislav Malyshev,
I would rather have int $num for coercive typing - given that close to
100% of existing typed functions - namely internal functions - mean
exactly that and are actually documented with this exact syntax.
[...]
As for strict, maybe it can be int! $num or something like
Stanislav Malyshev,
detriment of coercive types simply because there is no general
consensus about what strict means :)
I don't see any place for consensus and non-consensus here -
unless you want to redefine words to have arbitrary meanings so nobody
understands you, it is pretty clear
Hi!
The hole point (at least for me) for being against `function bar(int
$num){}` to achieve type coercion is that the syntactic equivalent
code `function bar(array $numbers){}` won't do any coercion - (array)
$numbers - because BC break would be too big to handle.
Having
Hi!
detriment of coercive types simply because there is no general
consensus about what strict means :)
I don't see any place for consensus and non-consensus here - unless
you want to redefine words to have arbitrary meanings so nobody
understands you, it is pretty clear what strict means -
Hi!
Even Nikic presented different versions of strict proposals on an
old article
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html
I don't see different versions - I see one version of strict which
matches my description and which he unequivocally opposes.
On 15/01/15 07:26, Pavel Kouřil wrote:
And yesterday I was pointed out one thing: the RFC states With this
approach, an argument is only accepted if its type is exactly the same
as the parameter.. Does this mean you cannot pass integer to a
function with float argument in the strict mode?
One
On
15
Jan
2015,
at
0:33, Andrea Faulds a...@ajf.me:
Hi Marcio,
On 14 Jan 2015, at 18:52, Marcio Almada marcio.w...@gmail.com wrote:
We still have a BC break but now we also have code with **mutant**
behavior that might become buggy (do unexpected things) if a `declare` is
used. As a
Hey:
On Thu, Jan 15, 2015 at 6:42 AM, Andrea Faulds a...@ajf.me wrote:
Hey Dmitry,
On 14 Jan 2015, at 20:40, Dmitry Stogov dmi...@zend.com wrote:
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string
On Thu, Jan 15, 2015 at 9:29 AM, Lester Caine les...@lsces.co.uk wrote:
One of the nice features of PHP when I started using it all those years
ago was that I did not have to create separate functions different types
did exist in the source data. int/float/num/double and others all needed
On 15/01/15 08:49, Pavel Kouřil wrote:
One of the nice features of PHP when I started using it all those years
ago was that I did not have to create separate functions different types
did exist in the source data. int/float/num/double and others all needed
separate handling in c/c++, and
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, January 15, 2015 12:29 AM
To: Zeev Suraski
Cc: rquadl...@gmail.com; Leigh; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Zeev,
On 14 Jan 2015, at 13:35, Zeev Suraski z
Zeev Suraski wrote on 15/01/2015 11:56:
PLUS have the ability to radically
change how it behaves based on a runtime option. It's so bad that we
decided more than a decade ago that we want to refrain from ever introducing
such elements to PHP again (e.g. magic_quotes_runtime), and I'm not sure
Hi Stas,
On 14 Jan 2015, at 23:29, Stanislav Malyshev smalys...@gmail.com wrote:
I agree. Being wrong is bad, making a mistake is bad, but having split
personality language and not knowing in which world you are - or even
worse, having to deal with both worlds in the same code and being
Hi Zeev,
On 15 Jan 2015, at 11:56, Zeev Suraski z...@zend.com wrote:
Andrea,
I'm not sure what you're basing that assumption on. The incidental
interactions you (or anybody) may have with 'the community', by no way
represent the opinion of the community at large. The vast majority of
Hey Rowan,
On 15 Jan 2015, at 13:02, Rowan Collins rowan.coll...@gmail.com wrote:
Zeev Suraski wrote on 15/01/2015 11:56:
PLUS have the ability to radically
change how it behaves based on a runtime option. It's so bad that we
decided more than a decade ago that we want to refrain from
The main advantage of the two syntaxes:
1. Strict
function bar(int $num){}
2. Weak
function bar((int) $num){}
Any junior-middle PHP developer, seeing this syntax in the code can
understand how it works, without studying the documentation and without
your complex conversion tables.
Explicit is
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, January 15, 2015 4:10 PM
To: Zeev Suraski
Cc: rquadl...@gmail.com; Leigh; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Zeev,
Whether or not they are in the majority, a very
That's how all internal functions work. It looks like you didn't
actually read my argument but just repeated I want my use case.
Sorry, I read all you said and understood it perfectly.
I know you want strict typing. I even proposed the option for it.
No, you're wrong. I NEVER EVER said we
Andrea,
With all the respect this RFC is way worst than the v0.1:
We still have a BC break but now we also have code with **mutant** behavior
that might become buggy (do unexpected things) if a `declare` is used. As a
language user and a package maintainer it would be a huge problem. Imagine
how
Hi Andrea,
I have some notes about this RFC from a users POV with only little
knowledge about internals.
I didn't read 100% of the theads of this RFC so I'm sorry if some notes
of this email was already discussed.
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string $s), and it may be called with
integer argument e.g. strlen(123) - 3
I think user functions should follow the same rules.
If some rules are bad, lets
Hi Marc,
On 14 Jan 2015, at 19:01, Marc Bennewitz dev@mabe.berlin wrote:
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the same if you call a function in weak type mode
and calling a function in strict type mode with explicit cast.
But that would require to
Hi Marcio,
On 14 Jan 2015, at 18:52, Marcio Almada marcio.w...@gmail.com wrote:
We still have a BC break but now we also have code with **mutant** behavior
that might become buggy (do unexpected things) if a `declare` is used. As a
language user and a package maintainer it would be a huge
Hi Rowan,
On 14 Jan 2015, at 15:45, Rowan Collins rowan.coll...@gmail.com wrote:
Perhaps it would be clearer if the RFC (and the documentation, if this is
accepted) referred to the non-strict as something other than weak. It makes
it sound like only a weak check will be performed, and
hi Andrea,
On Wed, Jan 14, 2015 at 1:16 AM, Andrea Faulds a...@ajf.me wrote:
Good evening,
I’ve made some quite significant changes to my Scalar Type Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a
Hi Zeev,
On 14 Jan 2015, at 13:35, Zeev Suraski z...@zend.com wrote:
I don’t think we’re ever going to get consensus. But judging by the feedback
to the v0.1 version, I tend to disagree that the opposers would have blocked
it. There were certainly opposers – but not that many of them as
Andrea Faulds wrote:
From what I can see, the larger PHP community is generally in favour
of strict typing, and among them, the previous RFC revision was
received quite poorly. Myself, I might have been somewhat happy with
just weak hints, but it would upset an awful lot of developers who
Hi!
We’re definitely not going to have consensus on introducing both options as
per this RFC. I for one think it’s the worst possible option.
I agree. Being wrong is bad, making a mistake is bad, but having split
personality language and not knowing in which world you are - or even
worse,
Hey Dmitry,
On 14 Jan 2015, at 20:40, Dmitry Stogov dmi...@zend.com wrote:
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string $s), and it may be called with
integer argument e.g. strlen(123) -
2015-01-14 16:00 GMT+02:00 Pavel Kouřil pajou...@gmail.com:
Hello,
personally, as a language user, I really dislike the idea of both
options for scalar type hinting to be the part of the language.
Especially since you would have to declare the strict typing in each
file (if you are going by
On 01/14/2015 02:35 PM, Zeev Suraski wrote:
I don’t think we’re ever going to get consensus. But judging by the
feedback to the v0.1 version, I tend to disagree that the opposers would
have blocked it. There were certainly opposers – but not that many of them
as far as I could tell. I
On 14 January 2015 at 14:00, Pavel Kouřil pajou...@gmail.com wrote:
PS: Personally, I find the scalar typehint idea useless and cannot
find a real use case for it. Richard, would you mind giving an
example?
The point of the 'scalar' typehint comes about because we need to reject
non
On Wed, Jan 14, 2015 at 11:28 PM, Andrea Faulds a...@ajf.me wrote:
From what I can see, the larger PHP community is generally in favour of
strict typing, and among them, the previous RFC revision was received quite
poorly. Myself, I might have been somewhat happy with just weak hints, but it
Andrea Faulds wrote on 14/01/2015 13:15:
Hi Thomas,
On 14 Jan 2015, at 13:04, Thomas Nunninger tho...@nunninger.info wrote:
Sorry, if my mail was not clear. My point was: If I write a library in strict
mode and someone else is using it from his non-strict mode, he can pass an
integer to
Hey Robert,
On 14 Jan 2015, at 08:22, Robert Stoll p...@tutteli.ch wrote:
I had a few thoughts on the new proposed declare(strict_typehints=TRUE);
construct and I must say I do not really like that we would have different
behaviour just based on a directive. This is quite ugly from a
On 14 January 2015 at 00:16, Andrea Faulds a...@ajf.me wrote:
Good evening,
I’ve made some quite significant changes to my Scalar Type Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision
Hi Thomas,
On 14 Jan 2015, at 13:04, Thomas Nunninger tho...@nunninger.info wrote:
Sorry, if my mail was not clear. My point was: If I write a library in strict
mode and someone else is using it from his non-strict mode, he can pass an
integer to myFunc() without an error. If I use this
On 14 January 2015 at 09:41, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, January 14, 2015 11:33 AM
To: Leigh
Cc: PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Leigh,
On 14
List
*Subject:* Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On 14 January 2015 at 09:41, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Wednesday, January 14, 2015 11:33 AM
To: Leigh
Cc: PHP Internals List
Subject: Re: [PHP
Hi Thomas,
On 14 Jan 2015, at 10:08, Thomas Nunninger tho...@nunninger.info wrote:
$i = 1;
$a = myFunc( $i );
declare(strict_typehints=TRUE);
function myFunc( float $f )
{
return otherFunc( $f );
}
function otherFunc( float $f )
{
...
}
Hi,
On 01/14/2015 10:32 AM, Andrea Faulds wrote:
Hi Leigh,
On 14 Jan 2015, at 09:17, Leigh lei...@gmail.com wrote:
I really don't like this behaviour being changed at the call site. If
I design a function that I _know_ should only take a string, then I
want it to be an error if the user
Hi Andrey,
On 14 Jan 2015, at 11:10, Andrey Andreev n...@devilix.net wrote:
I don't understand why it should be a bad thing that the API author
forces rules on the consumer. The opposite is IMO fundamental to the
concept of an API - the rules specified by the author are a contract
that the
On Wed, Jan 14, 2015 at 1:16 AM, Andrea Faulds a...@ajf.me wrote:
Good evening,
I’ve made some quite significant changes to my Scalar Type Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant
Hi Julien,
On 14 Jan 2015, at 10:14, Julien Pauli jpa...@php.net wrote:
Using declare() IMO, is a PITA.
Everything that can be done without the use of declare(), must be done
without declare().
I would have prefered different syntax, like the ones we disccussed many
years ago ,
Hello,
On Wed, Jan 14, 2015 at 12:22 PM, Andrea Faulds a...@ajf.me wrote:
Hi Julien,
On 14 Jan 2015, at 10:14, Julien Pauli jpa...@php.net wrote:
Using declare() IMO, is a PITA.
Everything that can be done without the use of declare(), must be done
without declare().
I would have
Hi again,
On Wed, Jan 14, 2015 at 1:21 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 14 Jan 2015, at 11:10, Andrey Andreev n...@devilix.net wrote:
I don't understand why it should be a bad thing that the API author
forces rules on the consumer. The opposite is IMO fundamental to the
option.
Zeev
*From:* Richard Quadling [mailto:rquadl...@gmail.com]
*Sent:* Wednesday, January 14, 2015 3:23 PM
*To:* Zeev Suraski
*Cc:* Andrea Faulds; Leigh; PHP Internals List
*Subject:* Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On 14 January 2015 at 09:41, Zeev Suraski z...@zend.com
Hi Andrea,
On 01/14/2015 11:20 AM, Andrea Faulds wrote:
Hi Thomas,
On 14 Jan 2015, at 10:08, Thomas Nunninger tho...@nunninger.info wrote:
$i = 1;
$a = myFunc( $i );
declare(strict_typehints=TRUE);
function myFunc( float $f )
{
return otherFunc( $f );
}
function
On Wed, 31 Dec 2014, Stanislav Malyshev wrote:
The issue is the class names though. E.g. see:
https://github.com/ralphschindler/zf2-db/blob/master/research/ColumnType/Integer.php
That's in a namespace, so it's not actually Integer, but
Zend\Db\Metadata\Type\Integer
and:
On 04.01.15 04:43, Pierre Joye wrote:
I agree with your sentiments about data loss, but I am reluctant to
deviate much from the behaviour of internal functions to avoid the
inconsistency that plagued the previous RFC.
Right, but this is what I would expect. Am I the only one?
Definitely
2015-01-04 18:31 GMT+01:00 Derick Rethans der...@php.net:
On Wed, 31 Dec 2014, Stanislav Malyshev wrote:
The issue is the class names though. E.g. see:
https://github.com/ralphschindler/zf2-db/blob/master/research/ColumnType/Integer.php
That's in a namespace, so it's not actually Integer,
Hey Sebastian,
On 4 Jan 2015, at 19:02, Sebastian B.-Hagensen sbj.ml.r...@gmail.com wrote:
It might add some value to forbid importing of unaliased type named
classes via use, so that no ambiguous type annotation exists.
Example:
use My\Lib\string as UserString; // fine, no error
use
Hi!
That's in a namespace, so it's not actually Integer, but
Zend\Db\Metadata\Type\Integer
Right, but it doesn't matter - in the same namespace (and in ones with
suitable imports), foo(Integer $bar) still means the class, not the
primitive type, and that would be broken by this RFC. Also, if
Hi Stas,
On 4 Jan 2015, at 23:58, Stanislav Malyshev smalys...@gmail.com wrote:
I think it's perfectly acceptable that PHP makes a built-in type a
reserved word. I would certainly not change it to PHPInt to avoid any
obvious clashes.
As I already pointed out, if we make it reserved
On 5 January 2015 at 01:07, Andrea Faulds a...@ajf.me wrote:
Hi Stas,
On 4 Jan 2015, at 23:58, Stanislav Malyshev smalys...@gmail.com wrote:
I think it's perfectly acceptable that PHP makes a built-in type a
reserved word. I would certainly not change it to PHPInt to avoid any
obvious
Here is what I run on my ubuntu 14.04 for compiling testing:
apt-get install build-essential re2c bison
git clone -b master https://github.com/php/php-src.git
cd php-src
curl https://github.com/php/php-src/pull/972.patch | git am
./buildconf
./configure
make
sapi/cli/php /tmp/test.php
test.php
- on-numeric strings not accepted. Numeric strings with trailing
characters are accepted, but produce a notice.
I would rather not allow fancy conversions here. Any trailing non
white spaces characters should not be allowed. I know it is not what
PHP does now in some cases but this is really
Hey Pierre,
Thanks, great work and persistent effort!
Thank you.
As I am also slightly in favor of a strict way, this RFC is a good compromise.
Some comments:
- on-numeric strings not accepted. Numeric strings with trailing
characters are accepted, but produce a notice.
I would
On 03.01.2015 05:50, Pierre Joye wrote:
I am also not a fan of errors, exception, at least for methods, make
much more sense. I know it is relatively easy to handle errors as
exception but still, let do it right now.
I second this; this could be an excellent opportunity into that
direction
Hi Sebastian,
On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen sbj.ml.r...@gmail.com wrote:
Yeah, I don’t like this behaviour much. I want to avoid inconsistency with
the behaviour of extension functions (i.e. zend_parse_parameters) where
possible, though. Since this has come up so much, I
Hi Thomas,
On 3 Jan 2015, at 20:00, Thomas Bley ma...@thomasbley.de wrote:
Here is what I run on my ubuntu 14.04 for compiling testing:
apt-get install build-essential re2c bison
git clone -b master https://github.com/php/php-src.git
cd php-src
curl
Hi,
On Jan 4, 2015 3:10 AM, Andrea Faulds a...@ajf.me wrote:
Hi Sebastian,
On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen sbj.ml.r...@gmail.com
wrote:
Yeah, I don’t like this behaviour much. I want to avoid inconsistency
with the behaviour of extension functions (i.e.
On Fri, Jan 2, 2015 at 9:54 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I am not sure about that. Parameters handling is one specific case,
userland parameter handling even more. It could be a good move to do
Making internal and userland parameters work differently and having
Hi!
I am not sure about that. Parameters handling is one specific case,
userland parameter handling even more. It could be a good move to do
Making internal and userland parameters work differently and having
scalar type errors behave differently from object type errors by having
one throw
Hello Jordi,
On 02.01.2015 15:01, Jordi Boggiano wrote:
Looking at it from an OSS maintainer perspective, introducing strict
hints in code would be a huge BC break as I don't know how people use my
code, nor if they validate/coerce their user input early or not. If I
suddenly declare
hi Andrea,
On Wed, Dec 31, 2014 at 12: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
On Fri, Jan 2, 2015 at 9:05 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I am also not a fan of errors, exception, at least for methods, make
much more sense. I know it is relatively easy to handle errors as
exception but still, let do it right now.
Then we need to convert all
Am Thu, 1 Jan 2015 14:41:06 +0200
schrieb Zeev Suraski z...@zend.com:
Hallo,
† Numeric strings with trailing characters and non-numeric strings are
accepted, but produce a notice.
Why Scalar Type Hints? What is the goal?
- Hints for IDEs - autocompletion?
- Find bugs with static program
Hi!
I am also not a fan of errors, exception, at least for methods, make
much more sense. I know it is relatively easy to handle errors as
exception but still, let do it right now.
Then we need to convert all parameter mismatch errors (or at least all
fatal ones) to exceptions. Which I don't
Syntax forced cast, it makes sense not only for scalar types, but also for
instances of classes.
Is a syntactic sugar can be realized
?php
class User
{
public function __construct(int $id)
{
..
}
}
function printPerson((User) $object)
{
var_dump($object);
return
Hey Matthew,
On 2 Jan 2015, at 16:35, Matthew Leverton lever...@gmail.com wrote:
I'd much prefer if they were strict types. I have a bias toward this
because I prefer to be as strict as possible. It's not hard to type
my_func((int) $_GET['foo']) if I want easy conversion. This explicit
On Wed, Dec 31, 2014 at 2:27 PM, Andrea Faulds a...@ajf.me wrote:
Please read the RFC (and specification patch, if you wish) and tell me your
thoughts.
My thoughts as a long time (non-voting) PHP user:
I'd much prefer if they were strict types. I have a bias toward this
because I prefer to
On 2 January 2015 at 01:01, Stanislav Malyshev smalys...@gmail.com wrote:
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.
On 02.01.15 05:36, Levi Morrison wrote:
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.
Same from me. I support all arguments so far made by Nikita;
On 2 January 2015 at 14:00, Andrea Faulds a...@ajf.me wrote:
Hi Marco,
On 2 Jan 2015, at 09:16, Marco Pivetta ocram...@gmail.com wrote:
I'm not sure why everyone is still taking the PHP manual as a good
reference about how to write software: PHP internal functions are one of
the main
Hi Marco,
On 2 Jan 2015, at 09:16, Marco Pivetta ocram...@gmail.com wrote:
I'm not sure why everyone is still taking the PHP manual as a good reference
about how to write software: PHP internal functions are one of the main
reason why this language is under-appreciated.
The manual is
On Thu, Jan 01, 2015 at 06:53:00PM -0600, Larry Garfield wrote:
The end users of php-src are people who write PHP code. Those
are the end users that we should be concerned with. People who
visit web sites are *their* end users. Those people don't care in
the slightest what happens on this
On 2 Jan 2015, at 13:15, Marco Pivetta ocram...@gmail.com wrote:
The manual is wrong since it specifies a strict hint for something that is
`mixed`. It is still useful tho, since it's telling us it accepts
integer-ish values there. It's purely for documentation purposes though, it
is by
On 02/01/2015 10:54, Markus Fischer wrote:
On 02.01.15 05:36, Levi Morrison wrote:
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.
Same from me. I
Hey Jordi,
On 2 Jan 2015, at 14:01, Jordi Boggiano j.boggi...@seld.be wrote:
And I, on the other hand, disagree.
Looking at it from an OSS maintainer perspective, introducing strict hints in
code would be a huge BC break as I don't know how people use my code, nor if
they
On 02/01/2015 14:06, Marco Pivetta wrote:
Regardless if this RFC gets through or not, changing the signature of a
method IS a BC break in any case, so you shouldn't just move your `int`
declaration from the docblocks into the method signature.
On public methods yes although a lot of internal
On 2 January 2015 at 15:01, Jordi Boggiano j.boggi...@seld.be wrote:
Looking at it from an OSS maintainer perspective, introducing strict hints
in code would be a huge BC break as I don't know how people use my code,
nor if they validate/coerce their user input early or not. If I suddenly
Hi Alain,
On 2 Jan 2015, at 11:45, Alain Williams a...@phcomp.co.uk wrote:
There is a 3rd camp: (c)
These are the language implementors, in particular 3rd parties eg HipHop.
These
do care if a variable is int 42 or string 42 because there are optimisations
to be made if they know that a
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
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
-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
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
101 - 200 of 228 matches
Mail list logo
