Le Thu, 26 Mar 2020 21:28:38 +0100, Stanislav Malyshev
a écrit:
Hi!
On 3/26/20 1:26 PM, David Rodrigues wrote:
I agree with Tovilo. It is weird and confusing. Actually I never know
that it was possible.
You seem to contradict yourself - if you never knew it was possible, how
could you ever
Le Tue, 19 Dec 2017 04:34:24 +0100, Michael Moravec
a écrit:
Hello internals,
I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehint
The purpose of this RFC is to introduce "mixed" typehint on language
level
to be used
as a valid typehint.
Le Fri, 02 Dec 2016 14:54:04 +0100, Matteo Beccati a
écrit:
On 02/12/2016 08:36, Thomas Nunninger wrote:
Hi,
So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T
I second that. Why do you pri
Le Thu, 17 Nov 2016 23:19:38 +0100, Adam Baratz a
écrit:
Hi,
Based on my second thoughts on my initial approach, I created an RFC to
supplant it:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2
I believe this better addresses the negative feedback from the original
Hi,
Is it 2/3+1 or 1/2+1 ? I haven't seen it in the RFC.
Cheeers.
Le Fri, 10 Jun 2016 12:38:04 +0200, Joe Watkins a
écrit:
Afternoon internals,
The vote for typed properties has been restarted.
Please take part: https://wiki.php.net/rfc/typed-properties
Cheers
Joe
--
Utilisa
Le Wed, 25 May 2016 21:40:28 +0200, Fleshgrinder a
écrit:
and unset simply because the property is not
explicitly assigned null by unset, it is being undefined.
Because null !== undefined. That's why you get an error after an
unset($this->var), and you don't get one after $this->var = nu
If I was a popular framework creator, this wouldn't stop me. I would
release two packages : one for 7.0, another one for 7.1. And the 7.0 one
would be the 7.1 one that has been processed through a script to remove
any <<>> syntax, or to transform it (if pre/post attributes instructions
were
Hi,
Le Tue, 03 Nov 2015 20:22:12 +0100, Sammy Kaye Powers a
écrit:
Hey internals!
The RFC to allow trailing commas to function calls & declarations has
been
withdrawn in favor of the a RFC that broadens the scope to all list
syntax.
https://wiki.php.net/rfc/list-syntax-trailing-comma
Hi,
Le Wed, 30 Sep 2015 18:15:09 +0200, Scott Arciszewski
a écrit:
This is probably answerable by a quick yes/no and shouldn't need a ton
of bikeshedding, but if that happens anyway I apologize in advance.
I think random_bytes() and random_int() are great; they provide a
much-needed buildi
Le Sat, 19 Sep 2015 19:44:01 +0200, "François Laupretre"
a écrit:
Le 19/09/2015 14:25, Rowan Collins a écrit :
- a syntactic sugar for array_key_exists and property_exists, maybe
called hasitem(); hasitem($foo['bar']) would check $foo has the item
'bar', but hasitem($foo) would be an er
Le Fri, 18 Sep 2015 20:38:12 +0200, Rowan Collins
a écrit:
Benoit Schildknecht wrote on 18/09/2015 19:24:
I agree. exists() would allow PHP devs to make more secure, cleaner and
lighter code. It fills a gap and would be useful to a lot of devs.
On the contrary, I think code using exists
Le Fri, 18 Sep 2015 19:40:50 +0200, Robert Williams
a écrit:
On Sep 18, 2015, at 10:27, Lester Caine wrote:
All I am saying is that 'exists()' is simply part of the toolkit that
goes WITH extract(). There is a suitable tool in arrays and in objects
so why not complete the toolkit in straigh
Bumping in (senior dev here).
I think this function must be implemented.
Every dev I've seen in my company use isset() as its name says it does :
"Is this variable set, whatever its value is ?". That's exactly how we use
it in the code. And we use "null" a lot too. For us, "null" is a value
al Message-----
From: Benoit Schildknecht [mailto:bensor...@neuf.fr]
Sent: Friday, June 12, 2015 9:19 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: PHP 7.0.0alpha1 Released for Testing!
Le Fri, 12 Jun 2015 02:53:48 +0200, a écrit:
> Hi,
>
> The first alpha for 7.0.0 was just
Le Fri, 12 Jun 2015 02:53:48 +0200, a écrit:
Hi,
The first alpha for 7.0.0 was just released and can be downloaded from:
https://downloads.php.net/~ab/
The Windows binaries are available at
http://windows.php.net/qa/
This is the start of a new PHP era! Thanks everyone who made and helped
t
Le Tue, 19 May 2015 17:28:34 +0200, Nikita Popov a
écrit:
Hi internals!
For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved an
Le Wed, 11 Mar 2015 16:10:44 +0100, Zeev Suraski a écrit:
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@
last
week:
1. Accept string->bool and int->bool conversions (false->bool is not
supported)
Le Sat, 21 Mar 2015 18:44:23 +0100, Pierre Joye a
écrit:
On Mar 21, 2015 11:55 PM, "Zeev Suraski" wrote:
Sent from my mobile
> On 21 במרץ 2015, at 18:05, Rasmus Lerdorf wrote:
>
>> On 03/21/2015 08:52 AM, François Laupretre wrote:
>> Now, after more calls from many of you to delay it,
Hi,
I think your idea is good.
Le Mon, 09 Mar 2015 15:11:01 +0100, Shawn McCool a
écrit:
There's a cultural disposition against re-purposing a symbol from one
major
version to the next. Let's consider that as fact and move on.
If I wanted to provide syntactic sugar to replace a symbol w
Hi,
I think the new functions must have consistent parameters order too. I
think it is about the right time, so we'll have a cleaner and more logical
language.
ATM, it's a real headache, we constantly have to read the documentation to
make sure we give the arguments in the right order.
Hi,
I like this idea. But I'm afraid of BC. There will be some scripts who
won't work after that, because they already use functions with these names.
But since we already have some BC for PHP 7, I think it's about the right
time to do this.
But we have to keep the old names for at least
Le Fri, 20 Feb 2015 13:54:26 +0100, Niklas Keller a écrit:
Hi internals,
"In Operator" is now in discussion phase.
It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc/context_sensitive_lexer.
Regards, Niklas
I agree. Context Sensitive Lexe
Hi Tim,
Le Wed, 18 Feb 2015 10:44:20 +0100, Tim Bezhashvyly
a écrit:
Dear internals,
my RFC was not about dropping just class constants but constants in
general. Now I realise that you are not ready for this and most likely
will never be. Thus I’m withdrawing my proposal.
Regards,
Ti
Le Tue, 17 Feb 2015 00:58:18 +0100, Sara Golemon a écrit:
On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre
wrote:
Once again, anyone can take over version 0.3, if it is so great. Why
don't you do it ?
I will play the game, stop working on my proposal, and vote 'yes' again.
But don't ask
Hi Andrea,
Le Sat, 14 Feb 2015 04:18:28 +0100, Andrea Faulds a écrit:
Hi everyone,
I’ve written a small RFC and patch to add a “void” return type:
https://wiki.php.net/rfc/void_return_type
Please have a read over it. I think this would be a simple, yet useful
addition.
Yup, totally use
Hi,
Le Sat, 14 Feb 2015 00:25:12 +0100, Nikita Popov a
écrit:
The question of whether EngineException should inherit from Exception is
something we do have to consider now. Personally I prefer not introducing
any special exception types that aren't caught by default. I think that
would only
Hi,
Le Thu, 12 Feb 2015 19:55:09 +0100, Thomas Punt a
écrit:
Hello PHP Internals!
I'd like to propose to make empty() a variadic, where if any arguments
passed in are considered empty, then false is returned - otherwise
return true.
I absolutely love this idea, and would make a good us
Hi Yasuo,
Le Tue, 10 Feb 2015 07:25:00 +0100, Yasuo Ohgaki a
écrit:
Updated wiki page.
https://wiki.php.net/rfc/dbc2
While I agree this RFC is going in the right direction, I don't like the
use of "require" and "return".
They are already used for something completely different, I think
28 matches
Mail list logo
