De : Brian Moon [mailto:br...@moonspot.net]
I agree here with Benjamin. The thing I have wanted in user land for
years is to be able to build a user land function that worked the way
internal functions do in terms of type checking without having to build
my own type checking system. Having
De : Damien Tournoud [mailto:d...@damz.org]
All those are due to a bug in substr(), that we see now only thanks to
proper type identification. There is no reason for substr() to ever return
a boolean. It really needs to be fix to always return a string.
Sorry, not a bug. Documentation is
On 28/02/15 08:40, François Laupretre wrote:
My opinion, but that's only mine, is that I would favor deprecating null to
scalar, even for internal functions. It would add deprecation messages but
we'd end up with a cleaner code.
null is a very specific 'state' for anybody working with
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
The funny thing is that the fix for this is:
- substr($image, strrpos($image, \n) + 1)
+ (string)substr($image, strrpos($image, \n) + 1)
Which is that sort of casting that is put forward as argument against the
dual/strict mode.
It is
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
Interestingly functions like is_infinite(), is_dir(), is_file() all expect
correct types like float or string here although from the naming convention
is_something i would expect it says just false on *anything* else (which
it almost does
De : Damien Tournoud [mailto:d...@damz.org]
But anyway, that's not even the point. The point is that return values that
worked in a world of transparent type-jungling will not work in a world
of stricter typing checks. Which means that we need:
(1) To accept that for now casting FALSE to
On 28/02/15 08:24, François Laupretre wrote:
Sorry, not a bug. Documentation is clear. You get 'string|false' from
substr() and send it to a function expecting 'string'. Most languages will
fail on this. It worked in PHP because of implicit casting from bool to
string. We just decided to
On Sat, Feb 28, 2015 at 12:55 AM, Andi Gutmans a...@zend.com wrote:
On Feb 27, 2015, at 11:36 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dmitry,
That's not to say there's anything wrong with this approach, nor that
there isn't a ton we can learn from it. I think it's a fantastic
Hi Stas,
On Sat, Feb 28, 2015 at 1:53 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
I have no intention to change current include/require syntax, except
adding
2nd parameter.
This is a bit misleading since include is not a function, so there's no
1st parameter. Instead, it's a syntax
Hi Rowan,
On Sun, Mar 1, 2015 at 3:46 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 28/02/2015 02:37, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for
Am 28.02.2015 um 20:08 schrieb Patrick Schaaf:
Am 28.02.2015 19:32 schrieb Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the
On 28/02/2015 02:37, Yasuo Ohgaki wrote:
Hi Rowan,
On Fri, Feb 27, 2015 at 8:25 PM, Rowan Collins
rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote:
Yasuo Ohgaki wrote on 27/02/2015 03:44:
Hi all,
This is RFC for removing allow_url_include INI option. [1]
On 28/02/2015 06:48, Joe Watkins wrote:
Morning internals,
This is just a quick note to announce my intention to ready this RFC
for voting next week.
I know I'm a little late maybe, I was real sick most of last week, so
couldn't do anything useful.
A couple of us intend to fix
VCS Account Rejected: desty rejected by rasmus /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 28.02.2015 19:32 schrieb Crypto Compress cryptocompr...@googlemail.com
:
class BankAccount {
function Add($amount) {
assert($amount 0);
// ... code block ...
}
}
Now the programmer implementing code block to gracefully handle $amount
0 has a problem. There is
Am 21.02.2015 um 04:10 schrieb Yasuo Ohgaki:
Hi Crypto,
On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress
cryptocompr...@googlemail.com mailto:cryptocompr...@googlemail.com
wrote:
AssertionExceptions are not intended to be caught, they are
intended to be seen, in a specific
Hi!
Hi all,
https://wiki.php.net/rfc/introduce_design_by_contract
This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
Please comment if you have any for this RFC.
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why not go
Hi,
Since no more issues appeared on discussion, the voting for the Context
Sensitive Lexer is now open. The voting will close in exactly 14 days
counting from now:
RFC: https://wiki.php.net/rfc/context_sensitive_lexer#votes
Since so few people participated on discussions, if you decide to vote
Hi all,
https://wiki.php.net/rfc/introduce_design_by_contract
This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
Please comment if you have any for this RFC.
I'll post RFC discussion for actual proposals soon. Please keep discussion
only about how vote should be done.
Thank
Hi Stas,
On Sun, Mar 1, 2015 at 12:32 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
https://wiki.php.net/rfc/introduce_design_by_contract
This is vote only RFC for 2 competing Design by Contract(DbC) RFCs.
Please comment if you have any for this RFC.
I don't see why the first one
Hi Crypto,
On Sun, Mar 1, 2015 at 3:32 AM, Crypto Compress
cryptocompr...@googlemail.com wrote:
sorry for the late answer. My point is about throwing exceptions
(assert.exceptions=1). I think it is wrong to allow to change code-flow by
ini-setting and in current context it is wrong to throw
Hi all,
On Thu, Feb 26, 2015 at 7:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Vote for script only include/require RFC is started.
This RFC closes one of the fatal security hole in PHP programs with
simple patch.
https://wiki.php.net/rfc/script_only_include
Hi!
The root cause of the issue here is preciseness of the setting.
I think you agree that current allow_url_include=Off with INI_SYSTEM is
not precise at all.
It is precise - it's doing exactly what it meant to do, separate local
wrappers from remote ones.
We need to consider local and
On 1 March 2015 at 03:32, Stanislav Malyshev smalys...@gmail.com wrote:
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why not go and implement an extension,
and put it in PECL, and then propose it for core inclusion, if it proves
popular?
Hi all,
I made vote only RFC and started discussion for voting
https://wiki.php.net/rfc/introduce_design_by_contract
Please feel free to correct/improve it.
I added note to our RFCs
https://wiki.php.net/rfc/dbc
---
This RFC is part of “Design by Contract Introduction” RFC
Hi all,
There are too many things that I would like to improve ;)
https://bugs.php.net/bug.php?id=69127
This bug is known fatal bug for session module. I proposed lazy_destroy
to fix
this before, but it declined.
I think the name was wrong. With the proposal, session module destories
session
26 matches
Mail list logo
