that is the attribute of some object that is
being serialized.
Well, can someone explain me why some code would need to serialize
exception in the 1st place?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On Mar 21, 2015 2:15 PM, Levi Morrison le...@php.net wrote:
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.
As you guessed, I don't think this is so important that we should
create a new fake object syntax
On Mar 21, 2015 11:55 PM, Zeev Suraski z...@zend.com wrote:
Sent from my mobile
On 21 במרץ 2015, at 18:05, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/21/2015 08:52 AM, François Laupretre wrote:
Now, after more calls from many of you to delay it, and as Zeev himself
seemed to
On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array() in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_array
This proposes
to interpretations and clear. A side effect,
it will also the lazy among us to actually use the RFC in a better way
without being stopped due to some writing issues :)
Thoughts?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
done, indirectly or this info could be detected using the stat cache
and the resolved path cache. However it may make this part of the
cache implementation a bit more trickier but it should be possible.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime
users want, to clean up such things, but we
decided not to have a 5.7 to prepare such removals, let act
accordingly.
cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in a way that it
changes what people votes for or against is not something I want to
see. We have to solve this issue. Learning by doing :)
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
in the same request. However I am not sure it is worth the
addition.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mar 20, 2015 12:14 AM, François Laupretre franc...@php.net wrote:
De : Zeev Suraski [mailto:z...@zend.com]
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC –
On Mar 18, 2015 4:01 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Florian Anderiasch [mailto:m...@anderiasch.de]
Sent: Wednesday, March 18, 2015 10:48 AM
To: Stanislav Malyshev; Stelian Mocanita
Cc: PHP Internals List
Subject: Re: [PHP-DEV] Vote process
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of
On Mar 18, 2015 6:42 PM, Patrick ALLAERT patrickalla...@php.net wrote:
Le lun. 16 mars 2015 à 21:34, Matthew Leverton lever...@gmail.com a
écrit :
(Although the irony of using =1 instead of =true isn't lost on me!)
Yes, I mentioned[1] that funny aspect earlier.
0 or 1 is explicitly
On Thu, Mar 19, 2015 at 12:19 PM, Christoph Becker cmbecke...@gmx.de wrote:
Pierre Joye wrote:
However, as of today, you are the blocking point when it comes to
improve the wiki RFCs, registration and voting areas.And this is
really becoming a problem. I am not talking about irregularities
.
Please refrain for talking about me or to me ever again. I will take
legal actions if this does not stop.
Thank you for your understanding.
No idea what you are talking about and really not interested to this kind
of discussion, but I am still waiting for the data to valid changes.
Cheers,
Pierre
On Mar 18, 2015 10:52 AM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
Private emails, pressure and what many, including myself, consider as
harassment is a big issue in many OSS projects, and for PHP too. I am
What exactly you are calling harassment?
Repeatedly, explicitly,
On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I didn't have my time to spent for the patch. So I don't verify this
by myself, but it seems common sense for this RFC.
So you voted against it without knowing how it actually works or aims to
work? I suggest you to do it now
On Wed, Mar 18, 2015 at 10:24 AM, Stanislav Malyshev
smalys...@gmail.com wrote:
Hi!
I think having clearer rules about what lobbying is permitted, and
introducing some rules on who can vote on what would be a better way
of limiting the effect of lobbying.
And pretty soon we'll have 100-page
follows the same rules, I ask you one more time
to provide the data of the current wiki so patches, changes etc can be
implemented in a safer way. You know where to reach me to provide it.
Thanks for your cooperation.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP
On Mar 17, 2015 9:42 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Tue, Mar 17, 2015 at 7:23 AM, Pierre Joye pierre@gmail.com wrote:
I very much appreciate your consistent effort to improve php, at all
levels.
However I won't comment on this RFC or any further RFCs trying
On Mar 17, 2015 7:05 AM, Peter Petermann ppeterman...@gmail.com wrote:
On March 16, 2015 2:32:39 PM GMT+01:00, Pascal Chevrel
pascal.chev...@free.fr wrote:
It's too late, Bob's Basic STH missed the schedule for PHP 7, it was
proposed way too late and the coercive STH RFC has just zero
On Mar 16, 2015 11:16 PM, Pavel Kouřil pajou...@gmail.com wrote:
I can't speak for anyone who voted, but personally, if I could vote, I
would voted no - not because I don't want to block people from
getting what they want, but because I sincerely think that having ANY
setting that changes
On Mar 16, 2015 11:07 PM, Jordi Boggiano j.boggi...@seld.be wrote:
On 16/03/2015 11:49, Pavel Kouřil wrote:
it's similiar to the safe_mode though. Sure, it's not as bad as INI
setting, but the intent is the same - a switch changing how code
behaves.
ini_set('memory_limit', 10); also
Hi Yasuo,
On Mar 17, 2015 9:01 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
I had this idea for a long time, but I didn't have time to mention.
Since I did mention this idea in basic type hints thread, I've
created RFC for it.
https://wiki.php.net/rfc/introduce-type-affinity
On Mar 16, 2015 6:46 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dennis,
On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki:
Caller _must_ satisfy callee requirements. This is simple principle to
write a secure
Hi,
On Mar 16, 2015 4:29 PM, Xinchen Hui larue...@php.net wrote:
Hey:
The most unaccept feature in current STH thing(v.5.0) is this.
acutaly, I believe in most applications, they will still keep this
off..
so why we introduce such thing?
beside this, I have a
On Mar 16, 2015 8:03 AM, Zeev Suraski z...@zend.com wrote:
All,
First, I decided not to propose Basic STH under my name, despite the fact
I
think that not committing to put it to a vote adds unneeded risk for
delivering STH in PHP 7.0. Whether or not it’s put to a vote will be up
to
Bob.
On Mar 16, 2015 8:58 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Sunday, March 15, 2015 11:34 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date
Change
On Mar 16, 2015 9:10 AM, Pierre Joye pierre@gmail.com wrote:
On Mar 16, 2015 8:58 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Sunday, March 15, 2015 11:34 PM
To: internals@lists.php.net
Subject
On Mar 16, 2015 8:41 AM, Zeev Suraski z...@zend.com wrote:
Stelian,
Respectfully, I think internals@ is being just a bit too uptight here.
First, I did ask Bob before doing this, and while he said he thought it
wasn't a good idea (mostly because of feedback such as yours) - he didn't
On Mar 16, 2015 2:41 AM, Michael Wallner m...@php.net wrote:
On 15 03 2015, at 16:36, Sebastian Bergmann sebast...@php.net wrote:
Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann:
I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
to the usage of intptr_t (see
. Big names backed by companies even more,
even if something is done on a private manner. We have to be extremely
careful on that. And we include myself.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On Mar 16, 2015 6:25 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Sunday, March 15, 2015 9:22 PM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
Voting for
work together to satisfy most needs because
hiding bugs are not good thing to do.
It does but I do not claim that there are no bug, every code has bugs
and they should be fixed.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On Mar 16, 2015 1:17 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 16, 2015 at 10:48 AM, Pierre Joye pierre@gmail.com
wrote:
Coercive type for general developers and strict type for library
developers
will
eliminate more type related bugs, more natural to average
, a warning in the worst
case?
If it is the sooner, only for few cases, then I will vote no as I
think it is not a good move. If the latter, I am all in.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On Mar 14, 2015 7:50 AM, Benjamin Eberlei kont...@beberlei.de wrote:
On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermebla...@gmail.com;
On Mar 14, 2015 9:03 AM, Zeev Suraski z...@zend.com wrote:
Maybe I was naïve, but I thought I had a better way to make both weak
strict camps happy,
By dropping strict despite all discussions, proposing a pandara box rfc by
changing the casting rules and now suddenly proposing to go vote to
On Mar 14, 2015 10:14 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermebla...@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar
On Mar 14, 2015 9:24 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: stelian.mocan...@gmail.com [mailto:stelian.mocan...@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:18 AM
To: Pierre Joye
Cc: Zeev Suraski; PHP internals; Benjamin
On Mar 14, 2015 9:47 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
I say it again: it should not be accepted. Or we can just scratch our rules
and
On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote:
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)
On Mar 12, 2015 8:30 AM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
On Mar 10, 2015 2:41 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre and all,
On Tue, Mar 10, 2015 at 11:59 AM, Pierre Joye pierre@gmail.com
wrote:
On Tue, Mar 10, 2015 at 1:48 PM, Xinchen Hui larue...@php.net wrote:
Hey:
On Tue, Mar 10, 2015 at 10:07 AM, Yasuo Ohgaki yohg
been proven to be a mess at best, or useless at worst.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
think?
As I tend to like the idea to cleanup things, adding warning and
deprecation warnings for the sake of it is not too appealing to me.
Especially for this kind of things.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
). Doing
so will trigger a build there, cleaner.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 5, 2015 at 12:29 PM, Adam Harvey ahar...@php.net wrote:
On 5 March 2015 at 12:21, Pierre Joye pierre@gmail.com wrote:
It would be good to do a pecl release for each of them, and mark the
package as deprecated/overseeded by mysqli (I let you choose). Doing
so will trigger
7 anymore until
things are fixed, if necessary.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, terrible at worst. It is pointless to do it after
almost two decades for some of them.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with
such topic for a while.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mar 4, 2015 9:18 AM, Rowan Collins rowan.coll...@gmail.com wrote:
On 3 March 2015 20:08:45 GMT, Lester Caine les...@lsces.co.uk wrote:
The piece of the jigsaw I am missing is at which point does it become
better to create a new extension for a complex object rather than
simply
writing a
On Mon, Mar 2, 2015 at 1:58 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Tue, Mar 3, 2015 at 6:40 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Mar 1, 2015 at 3:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
First of all, I have no intention removing old
was to go for the new
pseudo object for most scalar, something Nikita worked on with a
prototype, allowing something like $mystring-replace(...); But adding
name aliases only to get names_defined_correctly sounds like a bad
move to me.
Cheers,
Pierre
--
PHP Internals - PHP Runtime Development Mailing
easier to actually provide more
clean and modern APIs when possible. For the core, leaving them like
that is simply the best move. And let focus on the scalar object-like
proposal.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
On Mar 3, 2015 4:31 AM, Julien Pauli jpa...@php.net wrote:
Same to me, I voted no because we're gonna break something which is not
that bad and turn it to a clear breakage in one step.
I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0
and remove in 7.1 or 7.2 or
On Feb 27, 2015 5:23 PM, Xinchen Hui larue...@gmail.com wrote:
Hey Internals:
I was looking Bob's switch optimization..
then I start to worry about where is the place optimization should
goes..
in generally, PHP is a interpreted language. IMO, it should
compiler the PHP
the Unicode
text support. It should either be part of intl (and proposed to enable
intl always for 7, with other RFC) or main. Main has the advantage to
provide a easier integration with other extensions.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime
different from this PoC.
- I'm not planning to invest into it in the near future. (PHP-7 takes all
my time)
Consider it available for academic purposes only at this point.
Fantastic move! The way to do it! Thanks a lot!.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals
On Thu, Feb 26, 2015 at 3:57 PM, Zeev Suraski z...@zend.com wrote:
Drupal homepage: One new E_DEPRECATED warning, which seems to catch a
real bug, or at least faulty looking code:
$path = trim($path, '/'); // raises E_DEPRECATED, as $path is boolean
false.
return $path;
So far nobody
.
The implementation should be simpler and more efficient than using
declare().
It is too complex for what we need. The declare statement is as simple
as use.. present as the top of the file, has to be checked just like
use, no brainer for the users.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
On Thu, Feb 26, 2015 at 12:48 AM, Stanislav Malyshev
smalys...@gmail.com wrote:
Hi!
I'm cool with that idea but I also think it should be spelled out like `
random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but
that's because it's what Ruby names their CSPRNG
On Thu, Feb 26, 2015 at 4:29 PM, Matthew Weier O'Phinney
matt...@zend.com wrote:
I've taken some time the last couple days to compile both the Scalare Type
Hints
v0.5 (heretofor STHv5) and Coercive Scalar Type Hints (heretofore STHcoerce)
patches and test some code against them.
Thanks for
their apps with plenty of patch versions checks. This is the reason #2
why I am against your RFC, the #1 being the total lack of actual non
magic casting (read: strict), optionally enabled.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing
rules is better? I agree to totally disagree
here. I will never agree on changing these rules (or maybe in php12).
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
think it costs the compatibility break.
I fully agree and why I will vote no on that. Even if I know many
projects that won't even notice such changes. But I also have no idea
how many 1000s projects out there won't be as happy.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP
hi,
On Wed, Feb 25, 2015 at 5:39 PM, Pierre Joye pierre@gmail.com wrote:
I totally forgot to mention one thing in all my replies:
I love this addition and it is cruelly needed :)
I only have doubts about the implementations and the details I
explained in my other replies. It is also
constant effort to
improve PHP security from an end user point of view and I sadly
disagree with the solution he provides with this RFC.
Cheers,
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 25, 2015 2:34 PM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi Florian
On 25 February 2015 at 22:25, Florian Margaine flor...@margaine.com
wrote:
Hi,
Pascal Chevrel pascal.chev...@free.fr writes:
Hi people,
I hope this is not too much off topic but I saw today that
with
that, until the trick was discovered ;)
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. Like the bug I detected in the PHP code to
build phar.phar. So, I can go further : we are not breaking anything *and* we
are helping users to find undetected bugs in their codebase. Nice side
effect, isn't it ?
Again, see my previous comment in this mail.
Cheers,
--
Pierre
@pierrejoye
On Feb 24, 2015 12:04 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Pierre,
In fact I had planned for a future RFC where we allow
session.entropy_file to use using random_bytes(). So the best source
is chosen automatically. (If you think there are better sources not
covered
It should use the session.entropy_file setting as it aims to be the exact
same thing. It also allows custom entropy src (better ones for higher
demands) as well.
On Feb 23, 2015 10:36 PM, Sammy Kaye Powers m...@sammyk.me wrote:
The RFC to add a user-land API for an easy-to-use and reliable
On Feb 24, 2015 3:08 AM, Leigh lei...@gmail.com wrote:
On 24 February 2015 at 10:55, Pierre Joye pierre@gmail.com wrote:
It should use the session.entropy_file setting as it aims to be the
exact
same thing. It also allows custom entropy src (better ones for higher
demands) as well.
I
On Tue, Feb 24, 2015 at 5:23 AM, François Laupretre franc...@php.net wrote:
I think I was not clear. *Every* 'break' I report here won't generate
anything more than E_DEPRECATED in the final implementation. By definition.
Ne need to wait for a better patch.
How do you test apps with actual
On Tue, Feb 24, 2015 at 1:39 PM, Leigh lei...@gmail.com wrote:
On 24 February 2015 at 20:54, Pierre Joye pierre@gmail.com wrote:
On Feb 24, 2015 12:04 PM, Anthony Ferrara ircmax...@gmail.com wrote:
PERHAPS, it could be written in such a way that a PECL extension can
alter the RNG
On Feb 23, 2015 7:43 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Monday, February 23, 2015 4:14 PM
To: Zeev Suraski
Cc: Joe Watkins; PHP internals
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive
is not
something that can be easily fixed.
It is why i like the dual mode choices. There is nothing to port (except
the few things we had to break already), unless one app explicitly wants to
move to strict internally, partially or totally (don't see why one would do
that).
Cheers,
Pierre
to scalar type hinting as well).
I want to be able to write this:
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Feb 23, 2015 at 2:53 PM, Zeev Suraski z...@zend.com wrote:
Thanks for testing, but it's a bit premature to jump to conclusions.
First, disabling phar is in the patch instructions at
github.com/php/php-src/pull/1110 - it's a bug in phar that needs to be
fixed. We'll address it.
On Feb 23, 2015 2:48 PM, Rowan Collins rowan.coll...@gmail.com wrote:
On 22 February 2015 23:56:18 GMT, Pierre Joye pierre@gmail.com
wrote:
Can you all of you stop this madness with moving discussions off list?
It is detestable, against almost all openness and principles behind an
oss
Can you all of you stop this madness with moving discussions off list?
It is detestable, against almost all openness and principles behind an oss
project like php. If we can't discuss anymore design, plans, ideas etc on
the list then we are doomed, for good.
On Feb 22, 2015 3:49 PM, Anthony
On Feb 21, 2015 1:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye pierre@gmail.com wrote:
Assertion is only for development and testing.
We need errors or exceptions during development and testing, but
not in production
On Feb 21, 2015 4:29 PM, François Laupretre franc...@php.net wrote:
De : Anthony Ferrara [mailto:ircmax...@gmail.com]
Saying that turning on an optional and previously unavailable option
inside
code causing code breaks is any way a BC break is pure FUD.
Who talked of BC break for this ?
On Feb 21, 2015 2:02 PM, Zeev Suraski z...@zend.com wrote:
I agree we should have users avoid explicit casts. That's why the
dual-mode
proposal exists. If users don't want to control their types, they should
use the
default mode. And everything works fine.
This ignores the reasonable
the
changes against existing applications. I suspect the impact may not be
as small as we think. I can be wrong here but tests will tell me how
wrong I could be :)
And finally, this RFC only proposes one solution, so competitive RFCs
are still required to actually represent alternatives.
Cheers,
--
Pierre
initial comment, this RFC needs more
discussion and some other critical questions must be answered before
this RFC.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, Feb 21, 2015 at 10:28 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Pierre,
And finally, this RFC only proposes one solution, so competitive RFCs
are still required to actually represent alternatives.
That is a good thing. it should only propose one solution. Making a
single RFC
On Feb 21, 2015 2:08 AM, Tony Marston tonymars...@hotmail.com wrote:
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston tonymars...@hotmail.com
wrote:
I disagree. Exceptions were originally invented to solve the
wrong I could be :)
And finally, this RFC only proposes one solution, so competitive RFCs
are still required to actually represent alternatives.
Cheers,
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
at it, can we stop using that 'patently false', and stick for
constructive wording such as 'I disagree'?
I see nothing wrong with patently. I see much more wrong to totally
ignore feedback, ideas, replies etc. while playing the politically
correct writer. But I am being OT again.
Cheers,
--
Pierre
a way I would really not like to see again.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 19, 2015 at 7:00 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins pthre...@pthreads.org wrote:
Morning internals,
The expectations RFC is now in voting phase:
https://wiki.php.net/rfc/expectations#vote
I totally miss the Expectation
of view, so other can start to work on a
couple of key features. But it is too late. Let face it, some features
(like your RFC) will never make it post 7.0. We have to be realistic
about how things work now.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime
of this approach or we can rename Request For Comments to
Request to Accept as any kind of comments or feedback is simply not
taken into accounts.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On Fri, Feb 20, 2015 at 8:36 AM, Joe Watkins pthre...@pthreads.org wrote:
No, we did not
Yes, we did, which you could have found out, if you were really bothered:
https://marc.info/?l=php-internalsm=138213285708117w=2
You are kidding me here and I already answered to that:
2013-10-18
of discussion*.
Please stop saying it hasn't been discussed, it has, a lot.
Some stuff covered by this RFC have part of a bigger discussions about
many different things.
Did we have a [RFC][Discuss] thread to actually discuss this exact
RFC? No, we did not. And it is cruelly needed.
Cheers,
--
Pierre
On Feb 20, 2015 8:11 AM, Andrey Andreev n...@devilix.net wrote:
Hi,
On Fri, Feb 20, 2015 at 6:00 PM, Levi Morrison le...@php.net wrote:
On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev n...@devilix.net
wrote:
Agree on 'double' though ... if we want to discourage its usage, we
might even
On Fri, Feb 20, 2015 at 9:26 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anthony,
On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Dmitry
On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov dmi...@zend.com wrote:
On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye
601 - 700 of 4120 matches
Mail list logo
