On 02 Feb 2015, at 17:35 , Derick Rethans der...@php.net wrote:
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It changes type
Hi Dmitry and Sebastian,
On 4 Feb 2015, at 05:49, Sebastian Bergmann sebast...@php.net wrote:
Am 04.02.2015 um 06:44 schrieb Dmitry Stogov:
What do you think about using only lowercase type names for scalar type
hints? In this case we won't have to introduce any limitations.
This would
On 2 February 2015 17:09:30 GMT, Alain Williams a...@phcomp.co.uk wrote:
On Mon, Feb 02, 2015 at 05:00:08PM +, Andrea Faulds wrote:
Hi Andrey,
...
Just to give thanks to Andrea on persisting with a highly contentious
RFC, one
that has defeated several others over the years. I hope that we
Hi Andrea,
In you proposal you disable declaration of classes with names, that may be
used for scalar type hints - Int, Float, ...
What do you think about using only lowercase type names for scalar type
hints?
In this case we won't have to introduce any limitations.
function foo(int $a) //
Am 04.02.2015 um 06:44 schrieb Dmitry Stogov:
What do you think about using only lowercase type names for scalar type
hints? In this case we won't have to introduce any limitations.
This would be inconsistent with the rest of PHP being case-insensitive
and only lead to confusion.
--
PHP
Hi Dmitry,
On 2 Feb 2015, at 19:26, Dmitry Stogov dmi...@zend.com wrote:
Agree. Strict type checks are simple and may be implemented more efficient.
But in case we have to support both - weak and strict, this won't make any
advantage.
I think this still works even if we support both. The
Hello Andrea,
On 02.02.15 00:49, Andrea Faulds wrote:
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Version 0.3 of the RFC can be found here:
Hi Dmitry,
On 2 Feb 2015, at 09:24, Dmitry Stogov dmi...@zend.com wrote:
Will we able to call the same function using weak
type hinting from on file and with strict from the other?
Yes, for the parameter type hints anyway. That means that strict and weak
code is interoperable without
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As already said, we're just going around in circles at this point, but
a migration issue?
Whatever code using the scalar type hints should be *new* code in
userland.
Why not existing userland code? If only new
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It changes type hinting behavior per file scope, so, just to try strict
type hinting in
Hi,
On Mon, Feb 2, 2015 at 6:39 PM, Andrea Faulds a...@ajf.me wrote:
Hey Derick,
On 2 Feb 2015, at 16:35, Derick Rethans der...@php.net wrote:
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very
Hi Matthew,
On 2 Feb 2015, at 16:45, Matthew Leverton lever...@gmail.com wrote:
On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types
RFC has passed. The patch is a work in progress: it
Hi Andrey,
On 2 Feb 2015, at 16:57, Andrey Andreev n...@devilix.net wrote:
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As already said, we're just going around in circles at this point, but
Hi,
On Mon, Feb 2, 2015 at 6:17 PM, Andrea Faulds a...@ajf.me wrote:
Hi Markus,
On 2 Feb 2015, at 14:25, Markus Fischer mar...@fischer.name wrote:
- Since consensus on the strict mode does part the community (or, the
greater community also outside @internals) my impression is that the
On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Version 0.3 of the RFC can be found here:
Hi,
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As already said, we're just going around in circles at this point, but
a migration issue?
Whatever code using the scalar type hints should be
Hi Markus,
On 2 Feb 2015, at 14:25, Markus Fischer mar...@fischer.name wrote:
- Since consensus on the strict mode does part the community (or, the
greater community also outside @internals) my impression is that the
current best way to move forward would be
- get the rfc to only go for
Hey Derick,
On 2 Feb 2015, at 16:35, Derick Rethans der...@php.net wrote:
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It
So, one of the advantages of strict type hinting is the ability to catch
potential errors.
For example when we pass 67 to setBody(string $message).
Thanks. Dmitry.
On Mon, Feb 2, 2015 at 7:30 PM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 09:24, Dmitry Stogov
Hey everyone,
On 2 Feb 2015, at 16:50, Andrea Faulds a...@ajf.me wrote:
The implementation does work for testing. I still need to write tests for
return types but they seem to work. Parameter types are fully-working,
though, and they have extensive tests, so I know they’re working fine
On Mon, Feb 2, 2015 at 7:00 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:57, Andrey Andreev n...@devilix.net wrote:
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As
On Mon, Feb 02, 2015 at 05:00:08PM +, Andrea Faulds wrote:
Hi Andrey,
...
Just to give thanks to Andrea on persisting with a highly contentious RFC, one
that has defeated several others over the years. I hope that we will end up with
something acceptable to most and will be able to finally
Hi Dmitry,
On 2 Feb 2015, at 18:22, Dmitry Stogov dmi...@zend.com wrote:
So, one of the advantages of strict type hinting is the ability to catch
potential errors.
For example when we pass 67 to setBody(string $message).
Yes, that sort of thing is easily caught by strict type checks.
2015-02-02 21:12 GMT+02:00 Andrea Faulds a...@ajf.me:
Hi Dmitry,
On 2 Feb 2015, at 18:22, Dmitry Stogov dmi...@zend.com wrote:
So, one of the advantages of strict type hinting is the ability to catch
potential errors.
For example when we pass 67 to setBody(string $message).
Yes, that
On Mon, Feb 2, 2015 at 10:12 PM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 18:22, Dmitry Stogov dmi...@zend.com wrote:
So, one of the advantages of strict type hinting is the ability to catch
potential errors.
For example when we pass 67 to setBody(string $message).
Hi Dmitry,
--
Andrea Faulds
http://ajf.me/
On 2 Feb 2015, at 07:02, Dmitry Stogov dmi...@zend.com wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It changes type
Hi Dmitry,
On 2 Feb 2015, at 07:02, Dmitry Stogov dmi...@zend.com wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
I don't like the original. Weak types work to a degree, but they don't fulfill
the use case of a lot of
On 02 02 2015, at 00:49, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Version 0.3 of the RFC can be found here:
On 02/02/2015 09:49, Michael Wallner wrote:
On 02 02 2015, at 00:49, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Hi,
On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 07:02, Dmitry Stogov dmi...@zend.com wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
I don't like the original. Weak types
On 02/02/15 08:53, Matteo Beccati wrote:
I think v0.1 had pretty good chances to get accepted, but I’m not so
sure about anything that followed.
I’m definitely -1 on declare(strict).
I agree. I understand that someone might prefer strict typing, but
declare() seems so different from
Hi Andrey,
On 2 Feb 2015, at 08:55, Andrey Andreev n...@devilix.net wrote:
Hi,
On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 07:02, Dmitry Stogov dmi...@zend.com wrote:
As I already told, in my opinion, version 0.1 was the perfect
what about giving several voting options? yes/no for scalar type hints and
yes/no for declare-strict
Regards
Thomas
Michael Wallner schrieb am 2. Feb 2015 09:49:
On 02 02 2015, at 00:49, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types,
Hi Andrea,
On Mon, Feb 2, 2015 at 11:05 AM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 08:55, Andrey Andreev n...@devilix.net wrote:
Hi,
On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 07:02, Dmitry Stogov
On Mon, Feb 2, 2015 at 11:41 AM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 07:02, Dmitry Stogov dmi...@zend.com wrote:
As I already told, in my opinion, version 0.1 was the perfect solution
that
fit into PHP semantic very well.
I don't like the original. Weak
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Version 0.3 of the RFC can be found here:
https://wiki.php.net/rfc/scalar_type_hints
Thanks!
--
Andrea Faulds
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It changes type hinting behavior per file scope, so, just to try strict
type hinting in a big project, people will have to change every
On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds a...@ajf.me wrote:
Hi everyone,
Just a few small updates.
I’ve made a small change to this RFC. Instead of the strict mode syntax being
declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead.
This makes it a bit quicker to
Hi Pavel,
On 25 Jan 2015, at 08:38, Pavel Kouřil pajou...@gmail.com wrote:
personally I still don't like this RFC in it's current form and
shorter declare won't change it.
I didn’t expect that making it shorter would really change anyone’s opinions,
except perhaps those who don’t like the
On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds a...@ajf.me wrote:
Hi Pavel,
Hi, thanks for explaining some things.
It can *sometimes* be a lossless conversion. Only sometimes.
For float to int conversion:
* Floats have the special values INF, NAN and -NAN, which cannot be preserved
*
Hey Stas,
On 25 Jan 2015, at 04:14, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
going to a vote. That said, I do lean towards always strict, given
you can usually ensure your return type’s correct.
Wait, so we would have two modes, strict and non-strict, but also in
non-strict
Hi everyone,
Just a few small updates.
I’ve made a small change to this RFC. Instead of the strict mode syntax being
declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead. This
makes it a bit quicker to type - important given you’d need to type it a lot -
without
Hi!
going to a vote. That said, I do lean towards always strict, given
you can usually ensure your return type’s correct.
Wait, so we would have two modes, strict and non-strict, but also in
non-strict mode, return types still will be strict? Yay, consistency!
--
Stas Malyshev
On 16 January 2015 01:41:55 GMT, Stanislav Malyshev smalys...@gmail.com wrote:
debate. I'm just claiming that `(int) $num` is more explicit, has no
BC breaks and should, IMMO, be the preferred choice.
No, it should not be, and I just wrote two mails explaining why exactly
it should not. Here's
On 15/01/15 15:28, Niktia Nefedov wrote:
Consider what a mess was register_globals and problems it had, but at
least
it was a global setting. Declare will work on per file basis, and it will
end up even more of a mess.
I think PHP development community learned that lesson and that's why you
On Fri, Jan 16, 2015 at 11:08 AM, Lester Caine les...@lsces.co.uk wrote:
On 15/01/15 15:28, Niktia Nefedov wrote:
Consider what a mess was register_globals and problems it had, but at
least
it was a global setting. Declare will work on per file basis, and it
will
end up even more of a
On 16/01/15 11:05, Benjamin Eberlei wrote:
You keep bringing this up, but there is a workaround to manually enable
On PHP5.4 or later? We are stuck with 5.3 unless code is modified. Same
with other removed functions in 5.4.
register globals again if you need to have it for migration. It should
On Thu, 15 Jan 2015, Jordi Boggiano wrote:
On 14/01/2015 00:16, Andrea Faulds wrote:
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d be sensible to separate discussion of the updated RFC from the v0.1
Mike Willbanks wrote on 15/01/2015 16:55:
It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict). So I
don't really understand where the gains of this would come from and it
actually causes me concern in that what if a developer
Hi,
On Fri, Jan 16, 2015 at 2:29 PM, Rowan Collins rowan.coll...@gmail.com wrote:
Mike Willbanks wrote on 15/01/2015 16:55:
It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict). So I
don't really understand where the gains of
Andrey Andreev wrote on 16/01/2015 13:00:
Hi,
On Fri, Jan 16, 2015 at 2:29 PM, Rowan Collins rowan.coll...@gmail.com wrote:
Mike Willbanks wrote on 15/01/2015 16:55:
It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict). So I
Hi again,
On Fri, Jan 16, 2015 at 4:52 PM, Rowan Collins rowan.coll...@gmail.com wrote:
Specifically, I don't think a library author should be able to tell me that,
just because they're feeling picky, '42' and 42 are not equivalent when
calling their function. It does very little to protect
Andrey Andreev wrote on 16/01/2015 15:37:
With no attempt to argue, I just thought of another example, inspired
by the ones given in the RFC - it is fairly common for functions
dealing with times to only accept a UNIX timestamp or otherwise just a
single kind of a time unit, such as only a count
I was just surprised by the current behavior :)
$ cat ops.php
?php
function foo(string $str) {
}
foo(ops);
?
$ sapi/cli/php -n ops.php
Catchable fatal error: Argument 1 passed to foo() must be an instance of
string, string given in ops.php on line 2
It too me time to realize what is going on
On 14/01/2015 00:16, Andrea Faulds wrote:
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d be sensible to separate discussion of the updated RFC from the v0.1 RFC.
Reading the thread at this point shows so much
On Tue, Jan 13, 2015 at 6:16 PM, Andrea Faulds a...@ajf.me wrote:
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 to the RFC,
Hi Matthew,
On 15 Jan 2015, at 16:59, Matthew Leverton lever...@gmail.com wrote:
I don't like this at all. I'd prefer raising a new warning type (e.g.,
E_AUTOCAST) over this.
That error type would cause absolute chaos, unless people decided not to make
use of it. Custom error handlers are
Hello Mike,
On 15 Jan 2015, at 16:55, Mike Willbanks pen...@gmail.com wrote:
I actually quite disagree with that statement.
I don’t understand. I said either approach to scalar hints will upset a large
portion of the community”. Are you not demonstrating that point, in that you
don’t like
Hello Andrea,
On Thu, Jan 15, 2015 at 8:09 AM, Andrea Faulds a...@ajf.me wrote:
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
Hi Mike,
On 15 Jan 2015, at 17:07, Mike Willbanks pen...@gmail.com wrote:
I may not have described this clearly. If I make a library with a method
that states an int, the declarative syntax now makes me have to take both due
to your earlier comment on that userland would define the
On Jan 15, 2015, at 6:51 AM, Andrea Faulds a...@ajf.me wrote:
I’m not really sure this is true. I agree that strict types aren’t entirely
in keeping with the “PHP way”. However, there are plenty of people who are
against them not for that reason, but simply because they don’t work well
Hi Andrea,
On 15 Jan 2015, at 16:55, Mike Willbanks pen...@gmail.com wrote:
I actually quite disagree with that statement.
I don’t understand. I said either approach to scalar hints will upset a
large portion of the community”. Are you not demonstrating that point, in
that you don’t
Hi Pavel,
On 15 Jan 2015, at 15:25, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Reading the thread at this point shows so much confusion, it seems half the
people reading the spec misunderstood that the declare() line
On 15/01/2015 15:25, Pavel Kouřil wrote:
The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if the user forgets to
On 15/01/2015 16:01, Pavel Kouřil wrote:
On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano j.boggi...@seld.be wrote:
I mean that if someone wants strict typing they won't want to use weak hints
because that would coerce the data before they can verify it and ensure
their code is strictly typed.
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Reading the thread at this point shows so much confusion, it seems half the
people reading the spec misunderstood that the declare() line affects
function calls only and not the API/implementation level.
As much I
On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano j.boggi...@seld.be wrote:
I mean that if someone wants strict typing they won't want to use weak hints
because that would coerce the data before they can verify it and ensure
their code is strictly typed.
Therefore the best course of action is
On Thu, 15 Jan 2015 14:30:48 +0300, Arvids Godjuks
arvids.godj...@gmail.com wrote:
Hello Andrea!
Consider what a mess was register_globals and problems it had, but at
least
it was a global setting. Declare will work on per file basis, and it will
end up even more of a mess.
I think PHP
On 15/01/2015 15:31, Pavel Kouřil wrote:
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Right now, or with only weak hints, if a library decides to implement strict
typing, they'll skip the scalar hints and check types with something like
the assert lib [1]. A user
On 15/01/2015 15:30, Benjamin Eberlei wrote:
The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if
Hi Zeev,
On 15 Jan 2015, at 14:32, Zeev Suraski z...@zend.com wrote:
Whether or not they are in the majority, a very large portion of PHP
developers would prefer strict typing. In particular, the most vocal ones
would seem to. There are also a lot of PHP developers who would prefer
weak
Hi Zeev,
On 15 Jan 2015, at 15:10, Zeev Suraski z...@zend.com wrote:
Let’s have a look. From a quick skim over the thread for v0.1:
* In favour of weak types (or the RFC anyway): Adam, Stas, yourself,
Jordi,
Pierre,
You're definitely missing Dmitry (which helped with the RFC) as well
On 15/01/15 15:51, Andrea Faulds wrote:
Let’s have a look. From a quick skim over the thread for v0.1:
* In favour of weak types (or the RFC anyway): Adam, Stas, yourself, Jordi,
Pierre,
Count me in for v0.1.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, January 15, 2015 4:51 PM
To: Zeev Suraski
Cc: rquadl...@gmail.com; Leigh; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Zeev,
On 15 Jan 2015, at 14:32, Zeev Suraski z
On Thu, Jan 15, 2015 at 4:25 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be
wrote:
Reading the thread at this point shows so much confusion, it seems half
the
people reading the spec misunderstood that the declare() line
Hello together,
I have followed the discussion from the outside (as I am not to vote
here) but I am a (not representative) PHP developer.
I think the main problem here is that you mix two things up:
1. Scalar type hints for functions
2. Conversion rules
From what I have read, most of you agree
On 15/01/2015 15:10, Zeev Suraski wrote:
Except that is not the case for this proposal, which explicitly and
deliberately
prevents the directive affecting inclusion. The behaviour is impossible to
toggle at runtime, unless you’re using some weird extension which lets you
edit the flag on the
Hi Jordi,
On 15 Jan 2015, at 15:11, Jordi Boggiano j.boggi...@seld.be wrote:
On 14/01/2015 00:16, Andrea Faulds wrote:
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d be sensible to separate discussion of
Hi,
On Thu, Jan 15, 2015 at 5:31 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Right now, or with only weak hints, if a library decides to implement strict
typing, they'll skip the scalar hints and check types with
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Right now, or with only weak hints, if a library decides to implement strict
typing, they'll skip the scalar hints and check types with something like
the assert lib [1]. A user calling it with random data would *always*
For me personally, I would use strict hints for private/protected methods and
weak hints for public methods.
Regards
Thomas
Thomas Bley wrote on 15.01.2015 21:16:
What about doing both weak and strict with two different syntaxes?
public function __construct(string $name, $age as int,
On 15 January 2015 19:20:27 GMT, Andrey Andreev n...@devilix.net wrote:
Hi,
On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds a...@ajf.me wrote:
Now from that perspective I cannot rely that I am in strict and
would have to handle the default weak even although I declared in my
class that i wanted
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
Maybe it makes sense to put this option on the ballot if it passes a vote,
it will be possible to put an end to the discus?
Hi Andrey,
On 15 Jan 2015, at 19:20, Andrey Andreev n...@devilix.net wrote:
Consider this badly designed API:
declare(strict_typehints=TRUE);
const MODE_APPEND = 0;
const MODE_TRUNCATE = 1;
const MODE_PREPEND = 2;
function write_file(string $path, int $mode, string
Hi Andrea,
On Thu, Jan 15, 2015 at 9:52 PM, Andrea Faulds a...@ajf.me wrote:
Sure, weak typing is much poorer than strict typing for error checking. Does
that mean the user should be prevented from having the choice?
Are you simply opposed to the idea of weak types in general?
I am
Hi,
I would like to call everyone's attention, specially people
contributing directly to this RFC series, to what S.A.N just said:
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
Maybe it makes sense to put this option on the
Am 15.01.2015 um 20:45 schrieb Marcio Almada:
Hi,
I would like to call everyone's attention, specially people
contributing directly to this RFC series, to what S.A.N just said:
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
What about doing both weak and strict with two different syntaxes?
public function __construct(string $name, $age as int, $cuteness as float, bool
$evil) {
string $name // strict
$age as int // weak
$cuteness as float // weak
bool $evil // strict
as Syntax is taken from SQL92.
Regards
Thomas
Am 14.01.2015 um 23:39 schrieb Andrea Faulds:
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
On 15 January 2015 20:16:54 GMT, Thomas Bley ma...@thomasbley.de wrote:
What about doing both weak and strict with two different syntaxes?
public function __construct(string $name, $age as int, $cuteness as
float, bool $evil) {
string $name // strict
$age as int // weak
$cuteness as float //
Andrey Andreev wrote:
I like both, I want to use both for different use cases and I don't
see what is it that will be bad about co-existence.
Any library author who wants strictness *will* force it on you, even
if that means writing 3x times more code.
Why would a library author want such
Hi!
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
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. Yes,
there are
I think the problem with the current rfc is:
test(42);
function test(string $a) does test((string)$a);
function test(array $a) does not test((array)$a); although casting would be
possible.
So for consistency we might change the syntax or adapt array/object type hints
with casting (BC-break).
Hi!
I’m not really sure this is true. I agree that strict types aren’t
entirely in keeping with the “PHP way”. However, there are plenty of
people who are against them not for that reason, but simply because
they don’t work well for them. Plus, I’m not sure strict typing
I would say for
Hi Thomas,
On 15 Jan 2015, at 22:25, Thomas Bley ma...@thomasbley.de wrote:
I think the problem with the current rfc is:
test(42);
function test(string $a) does test((string)$a);
function test(array $a) does not test((array)$a); although casting would be
possible.
So for consistency
Hi,
On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds a...@ajf.me wrote:
Now from that perspective I cannot rely that I am in strict and would have
to handle the default weak even although I declared in my class that i
wanted strict mode which only affected the code inside of that file.
On 15 Jan 2015, at 19:52, Andrea Faulds a...@ajf.me wrote:
Sure, weak typing is much poorer than strict typing for error checking. Does
that mean the user should be prevented from having the choice?
Are you simply opposed to the idea of weak types in general?
Another way to put this:
I don't think any junior-middle php developer with understand how (int) works.
Just make a test and see how many will answer (int)'asd' with 1.
Regards
Thomas
S.A.N wrote on 15.01.2015 22:18:
The main advantage of the two syntaxes:
1. Strict
function bar(int $num){}
2. Weak
function
S.A.N,
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
Hi!
And to hell with the consistency argument. Since when did PHP become
*that* concerned about purity and high consistency levels? Call this a
The purity part should be addressed to strict proponents - it's their
purist sensibilities that are offended by converting '23' to 23 ;) As
for
1 - 100 of 231 matches
Mail list logo
