Hi!
This is actually already supported.
The SplClassLoader$mode does exactly that. The $mode can be one of these values:
- MODE_NORMAL: Throws error while attempting to include an unexistent file
Why this should even exist? It's never OK for generic autoloader to
produce any errors when it ca
Guilherme,
Comments inline
> Thanks immensely for your input.
> Without such action, it's extremely hard to improve the RFC. =)
> Awesome action from your side.
> I'll place my comments inline.
Thanks. I didn't really intend for my other comments to get so...
aggressive. I saw the proposal bei
Hi David,
On Fri, Nov 11, 2011 at 1:31 AM, David Muir wrote:
> On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
>> Hi Anthony,
>>
>> Thanks immensely for your input.
>> Without such action, it's extremely hard to improve the RFC. =)
>> Awesome action from your side.
>> I'll place my comme
On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
> Hi Anthony,
>
> Thanks immensely for your input.
> Without such action, it's extremely hard to improve the RFC. =)
> Awesome action from your side.
> I'll place my comments inline.
>
> On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara wrote
Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):
http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch
The change to zlist_clean is necessary because otherwise extension_l
Hi Anthony,
Thanks immensely for your input.
Without such action, it's extremely hard to improve the RFC. =)
Awesome action from your side.
I'll place my comments inline.
On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara wrote:
> Guilherme et al,
>
> Since you asked me for feedback on how I would
David
Sorry, I just RE read your reply. that's basically what you said, so in
essence I agree...
Anthony
On Nov 10, 2011 6:29 PM, "Anthony Ferrara" wrote:
> Well, the problem with adding methods later is that it will fatal any
> class that implements the old one. A big no no.
>
> You could g
Hey Arpad, looking through the code you added to
ext/standard/basic_functions.c it looks like you are doing some weird
key handling in the shutdown function hash.
In register_user_shutdown_function() you have:
zend_hash_update(BG(user_shutdown_function_names), function_name,
sizeof(function_name)
Hi!
As long as it is completely obvious what is being voted on and the
process is followed, the voting RFC rules are fine. It would be nice
though if we could iterate in order to get 2/3 approval on most
proposals. It is these 50/50 ones that are problematic and often boil
down to half the peopl
Well, the problem with adding methods later is that it will fatal any class
that implements the old one. A big no no.
You could get around that by doing something like traversable. Provide an
empty and non usable core SplAutoloader interface which is typehintable.
Then add a child SplClassAutolo
Surprised to say that I agree on just about everything you mentioned. I
would however love to see a useful autoloader included in core. I have
only one comment below.
> 4. The RFC should avoid implementing any pattern or style that may
> make future feature addition difficult or pose risks towards
Pierre Joye wrote:
If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because we have a edge case in a
pr
On 11/10/2011 01:17 PM, Pierre Joye wrote:
> If that's not the case, and after a 2nd thought, it is actually not
> the case, then we can just discard this whole thread and go back to
> code and proposals. I only find very disturbing to have to explain and
> argue so many times about that only beca
On Thu, Nov 10, 2011 at 10:17 PM, Pierre Joye wrote:
> On Thu, Nov 10, 2011 at 9:04 PM, Rasmus Lerdorf
> wrote:
> > On 11/10/2011 10:38 AM, Pierre Joye wrote:
> >> On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf
> wrote:
> >>
> >>> We are not talking about a specific RFC here. This discussion i
Hi List,
When testing out 5.4b2 , I've noticed that the default Phar stub runs
the first argument to Phar::createDefaultStub when run using the cli
server. Is this right? Should i file a bug?
Thanks
- Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
I've notice, back in PHP 5.4.0 beta 2, that this test was failing:
Bug #48555 (ImageFTBBox() differs from previous versions for texts with new
lines) [ext/gd/tests/bug48555.phpt]
So I went to https://bugs.php.net/bug.php?id=48555 and left a comment.
The same test still fails in 5.4.0RC1 and als
Maintenance of the Phar extension (bug fixing, documentation fixes, etc)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
All of the existing tests run.
I will make one change as per C. Jones request to use a const for the
hard coded 1024 window (since it's used twice).
Also, I am unable to run the php-tests.php with the -m (valgrind) on my
mac, so I'll need to run those on linux before I commit.
In the mean t
On Thu, Nov 10, 2011 at 9:04 PM, Rasmus Lerdorf wrote:
> On 11/10/2011 10:38 AM, Pierre Joye wrote:
>> On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf wrote:
>>
>>> We are not talking about a specific RFC here. This discussion is about
>>> changing the current way of voting.
>>
>> Yes, and that's
Hello!
Stas has packed PHP 5.4.0RC1 which you can find here:
http://downloads.php.net/stas/
The Windows team provides windows binaries which you find here:
http://windows.php.net/qa/
This is the first release candiate. No new features will be included
before the final version of PHP 5.
Hi!
Sure, but this is another great example. If you wrote an RFC that
basically said, "Let's rewrite the engine" I bet it would get a lot of
We already have such proposal. It's called unicode support. Everybody
talks about how great it would be to have one. If we had a vote, I bet
there woul
Hello folks,
We've run into problems related to using Postgres as a datastore for sessions,
which appears to be identified in bug report 52389
(https://bugs.php.net/bug.php?id=52389). We've tried the patch attached to the
ticket, and have not seen our issue resolved. What steps can we take to
Hello,
On Thu, Nov 10, 2011 at 11:45 AM, Pierre Joye wrote:
>
> We are not talking about giving a voice to totally irrelevant people
> but well known PHP project leaders, who already contribute to PHP in
> one way or another. We are not either talking about them telling us
> what to implement, or
On 11/10/2011 10:38 AM, Pierre Joye wrote:
> On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf wrote:
>
>> We are not talking about a specific RFC here. This discussion is about
>> changing the current way of voting.
>
> Yes, and that's what I'm talking about too.
Ok, then I guess I don't underst
Ronald,
Very well said. Thanks for the clarification.
Anthony
On Thu, Nov 10, 2011 at 2:49 PM, Ronald Chmara wrote:
> On Thu, Nov 10, 2011 at 8:09 AM, Anthony Ferrara wrote:
>>> However, and it is what we approved, OSS project leads have a voice,
>>> today and here. And they are not random pe
On 11/10/2011 11:44 AM, Ralph Schindler wrote:
> Hey all,
>
> I've spent a bunch of time tracking down this issue (which was
> intermittent at best) and have identified the problem and have a patch
> for the solution.
>
> Details here: https://bugs.php.net/bug.php?id=60164
>
> The attached patch
On Thu, Nov 10, 2011 at 8:09 AM, Anthony Ferrara wrote:
>> However, and it is what we approved, OSS project leads have a voice,
>> today and here. And they are not random people, they know sometimes
>> much better than us what should be added to the core (be language, or
>> functions in an extensi
Hey all,
I've spent a bunch of time tracking down this issue (which was
intermittent at best) and have identified the problem and have a patch
for the solution.
Details here: https://bugs.php.net/bug.php?id=60164
The attached patch is against trunk, PHP_5_4, & PHP_5_3.
Seeing as though I've
2011/11/10 Pierre Joye :
> On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
>> Some are blocking because they kinda feel forced if this is introduced.
>> Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
>> about 15 years ago.
>>
>> I guess that some voted "No" because of lack
Hi!
well even for proposals which got accepted. This is not about specific
proposals but about this exact discussion to go back to our old model.
I'm totally against it. That will kill any effort we have put to get
more contributors and feedback or help from our users.
Nobody talks about going
On 11/10/11 8:19 AM, Pierre Joye wrote:
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is
On Thu, Nov 10, 2011 at 6:38 PM, Stas Malyshev wrote:
> Hi!
>
>> See the votes, there is a patch, created by people able to maintain
>> it. It is especially obvious in this case as this RFC is supported by
>> a large part of our users.
>
> Able != will. There are tons of people able to fix bugs in
On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf wrote:
> We are not talking about a specific RFC here. This discussion is about
> changing the current way of voting.
Yes, and that's what I'm talking about too.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Int
On 11/10/2011 09:44 AM, Pierre Joye wrote:
> That's another myth spread by the opponents of making our process
> open. All RFCs proposed has been proposed with patches, implemented by
> the proposers, with or without the help of other core developers.
> Nobody ever succeed (except the alternative a
On Thu, Nov 10, 2011 at 5:40 PM, Rasmus Lerdorf wrote:
> If there is voting on an RFC related to php-doc stuff, then the
> meritocracy shifts to the main php-doc contributors. Same goes for
> testing-related issues. My vote on a doc issue carries considerable less
> weight than my vote on a src i
Hi!
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.
Able != will. There are tons of people able to fix bugs in PHP, yet some
stay unfixed for years.
"Supported by users" doesn'
On 11/10/2011 05:53 AM, guilhermebla...@gmail.com wrote:
> I don't think so. You have classified that php-src have more weight in
> voting because they do the biggest effort.
> That's great, but you're forgetting that php-doc, php-web and php-test
> do have a lot of effort too.
> The fact when it c
> 2) This isn't a "bunch" of developers, this is a bunch of the largest> used
> PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal),
Ok, I have to say it... You're a group of people who have done great
things. Good for you. Get over it. Stop trying to use that as a
justification or
> However, and it is what we approved, OSS project leads have a voice,
> today and here. And they are not random people, they know sometimes
> much better than us what should be added to the core (be language, or
> functions in an extension like spl).
Well, I would like to make a point here. Righ
Comments are inline.
On Thu, Nov 10, 2011 at 2:19 PM, Pierre Joye wrote:
> On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
> wrote:
>
>> You're mixing stuff here.
>> "RFC on PSR-0 support into PHP status" != "PSR-0 status"
>
> I do not. But we are confusing our old vision and what users are lo
maybe someone else would be also interested in fixing the build.
-- Forwarded message --
From: Ferenc Kovacs
Date: Thu, Nov 10, 2011 at 3:34 PM
Subject: Re: [PHP-CVS] svn: /php/php-src/branches/PHP_5_4/ NEWS
ext/standard/exec.c ext/standard/tests/general_functions/bug60116.phpt
To
Guilherme et al,
Since you asked me for feedback on how I would suggest improving the
RFC, so here it goes...
I think I need to make one thing clear first. I don't think that I
can vote yes for this RFC in principle (I just don't agree this
belongs in core). However, with that said if the RFC w
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
wrote:
> You're mixing stuff here.
> "RFC on PSR-0 support into PHP status" != "PSR-0 status"
I do not. But we are confusing our old vision and what users are looking for.
> However, *how* PSR-0 might be introduced into PHP, for those who uses
>
On Thu, Nov 10, 2011 at 11:00 AM, Stas Malyshev wrote:
> Nobody's blocking anything.
See the votes, that's pretty much us vs the rest. And it is not the
1st time (happened already in the past before we had the RFC process,
so it will become more and more visible.
>> And as far as I can see, the
Hi Jonathan,
On Thu, Nov 10, 2011 at 11:12 AM, Jonathan Bond-Caron wrote:
> On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
>>
>> Some would simply say "he only did that because he got 3 proposals
>> rejected". Others would say "he is pressuring A to be in PHP". But not.
>> I learned the
Hi Rasmus,
Comments inline.
On Thu, Nov 10, 2011 at 2:51 AM, Rasmus Lerdorf wrote:
> On 11/09/2011 07:01 PM, guilhermebla...@gmail.com wrote:
>> My short version of this entire email is very simple question. Is PHP
>> meritocracy based?
>
> It is.
I'd rather say "wort of, when interesting".
>
On Thu, Nov 10, 2011 at 11:07 AM, Stas Malyshev wrote:
> Hi!
>
>> can keep dreaming about our famous "let make it easy to people to
>> contribute", it won't work as we are not willing to give them a voice.
> I don't think one implies the other. If one helps PHP project it's great,
> really, but
On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
>
> Some would simply say "he only did that because he got 3 proposals
> rejected". Others would say "he is pressuring A to be in PHP". But not.
> I learned the hard way and multiple times to hear a big NO. But at the
> same time, I earn my
2011/11/10 Pierre Joye :
> hi Stas,
>
> On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev wrote:
>> Hi!
>>
>>> This attitude only makes me lose a lot of time answering questions
>>> instead of focusing on actual RFC stability. I want to propose
>>> something stable, I do not want to be pressured abou
On Thu, Nov 10, 2011 at 10:39, Pierre Joye wrote:
> On Thu, Nov 10, 2011 at 10:32 AM, Rasmus Lerdorf wrote:
>> On 11/10/2011 12:36 AM, Pierre Joye wrote:
>>> The last example of such a case is the SplClassLoader, the gap between
>>> our communities and us is getting even larger. I think it is tim
Hi!
can keep dreaming about our famous "let make it easy to people to
contribute", it won't work as we are not willing to give them a voice.
I don't think one implies the other. If one helps PHP project it's
great, really, but that doesn't mean one can have his pet feature pushed
through ove
Hi!
But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in "php does not enforce standard"). Even for something
that does not enforce anything if not used.
Nobody's blocking anything. I don't understa
On Thu, Nov 10, 2011 at 10:36 AM, Pierre Joye wrote:
> hi Stas,
>
> On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev
> wrote:
> > Hi!
> >
> >> This attitude only makes me lose a lot of time answering questions
> >> instead of focusing on actual RFC stability. I want to propose
> >> something stabl
On Thu, Nov 10, 2011 at 10:32 AM, Rasmus Lerdorf wrote:
> On 11/10/2011 12:36 AM, Pierre Joye wrote:
>> The last example of such a case is the SplClassLoader, the gap between
>> our communities and us is getting even larger. I think it is time to
>> consider their views and voices, especially as w
hi Stas,
On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev wrote:
> Hi!
>
>> This attitude only makes me lose a lot of time answering questions
>> instead of focusing on actual RFC stability. I want to propose
>> something stable, I do not want to be pressured about should the RFC
>> exist or not. I
On 11/10/2011 12:36 AM, Pierre Joye wrote:
> The last example of such a case is the SplClassLoader, the gap between
> our communities and us is getting even larger. I think it is time to
> consider their views and voices, especially as we get new contributors
> (you know, the people actually doing
hi Stas,
On Thu, Nov 10, 2011 at 8:12 AM, Stas Malyshev wrote:
> Nobody's "denying voice" to anybody. Anybody who's interested can feel free
> to come to the list and bring forward their arguments and defend them and
> convince people. However, if the situation comes out that a particular
> prop
57 matches
Mail list logo
