: just output the BOM to stdout without any
special handling. It's entirely possible that I've just missed a
Unicode-related option there, though.
Adam
[1] http://bugs.php.net/bug.php?id=22108
--
Adam HarveyPEAR Profile: http://pear.php.net/user/aharvey
2009/9/19 Carsten Wiedmann carsten_st...@gmx.de
Kalle Sommer Nielsen schrieb:
2009/9/19 Carsten Wiedmann carsten_st...@gmx.de:
So that's the next PHP release with a broken IPv6 support (after 5.2.10 and
5.3.0) and so it's not possible to update for some peoples.
Is there a bug # on
2009/12/27 Mike Wacker mwac...@cornellsun.com:
PHP's documentation for foreach states that if you iterate by reference
[foreach ($ii as $i) ...], you should unset $i after the loop. $i still
points to the last element of the array - updating $i or reusing it will
update the last element of
Account granting folks,
On 30 July 2012 10:01, Brandon Sky brandonskypime...@gmail.com wrote:
I am Brandon Sky Pimenta. I want to have a PHP development account because I
want to:amp;#13;amp;#10;* Maintain and translate php.net and PHPamp;#39;s
documentationamp;#13;amp;#10;* Become more
On 30 July 2012 16:02, Lester Caine les...@lsces.co.uk wrote:
Moving people from 5.2 is probably going to be as bad as killing off PHP4
and 4.6% of sites are still using that! But the main problem starting to
happen now is that developers are upgrading projects to use 5.3 and 5.4
features, but
On 2 August 2012 12:30, Kris Craig kris.cr...@gmail.com wrote:
First we'll need to consolidate the information regarding when each version
was EOL'd. Are they all in news announcements, or are they scattered
between announcements, listserv threads, etc? If we're going to do this,
we may as
On 2 August 2012 13:00, Adam Harvey ahar...@php.net wrote:
On 2 August 2012 12:30, Kris Craig kris.cr...@gmail.com wrote:
First we'll need to consolidate the information regarding when each version
was EOL'd. Are they all in news announcements, or are they scattered
between announcements
On 2 August 2012 15:56, Peter Cowburn petercowb...@gmail.com wrote:
On 2 August 2012 07:35, Adam Harvey ahar...@php.net wrote:
Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or
would we rather have a manual array?) Specific notes on
vulnerabilities to add to branches? Better
On 2 August 2012 16:51, Morgan L. Owens pack...@nznet.gen.nz wrote:
On 2012-08-02 20:42, Peter Cowburn wrote:
The details on things being obsoleted should be in the migration guides.
Then that would be where the links go, in a similar manner to the Changelog
links.
I've added links to the
On 2 August 2012 16:58, Adam Harvey ahar...@php.net wrote:
On 2 August 2012 16:51, Morgan L. Owens pack...@nznet.gen.nz wrote:
On 2012-08-02 20:42, Peter Cowburn wrote:
The details on things being obsoleted should be in the migration guides.
Then that would be where the links go, in a similar
On 15 August 2012 18:15, Nikita Popov nikita@gmail.com wrote:
As already pointed out repeatedly, argument typehints serve the
purpose of defining an interface. No, they are not required to run the
code, that's true. But they still serve an important purpose for
object oriented programming
On 3 September 2012 17:36, Andrew Faulds a...@ajf.me wrote:
Ryan McCue li...@rotorised.com wrote:
What about ISO8601 with the Olson timezone suffixed?
2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)
Sounds good.
If we're going to invent arbitrary
On 3 September 2012 19:54, Will Fitch willfi...@php.net wrote:
On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey ahar...@php.net wrote:
I just don't see how we can choose a sensible default format for
users. Sometimes you want ISO 8601. Sometimes you want whatever your
locale's customary date format
On 20 September 2012 16:24, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
On 9/19/12 2:01 PM, Andrew Faulds wrote:
$cb = {mysql_real_escape_string};
$cb = {mysql_real_escape_string};
These notations are just horrible.
Agreed. They're very line noisey and non-obvious.
PHP has
On 25 October 2012 13:46, JJ ja...@php.net wrote:
On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
theanomaly...@gmail.com wrote:
I understand there are people out there that don't read the
documentation and aren't aware of the difference between
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
On 25 October 2012 18:38, Sebastian Krebs krebs@gmail.com wrote:
2012/10/25 crankypuss fullm...@newsguy.com
Booleans ought to be 1 and 0. Casting a boolean to 2 is just wrong, a way
to fix badly written code a few people have written and in so doing risk
the breakage of far more code that
On 31 October 2012 06:18, Sara Golemon poll...@php.net wrote:
With the exception of renaming the UConverter::UCNV_* constants to
remove the UCNV_ prefix, I believe I've addressed the concerns thus
far. ((Waiting to hear if anyone else wants to weigh in on the
contants)) The RFC has been
Hi everyone,
I've written an RFC to cover deprecating ext/mysql in PHP 5.5:
https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft
deprecation in the documentation purely via a straw poll on Internals,
I presume this will end up needing to go to a vote, hence the RFC.
I won't
On 12 November 2012 21:20, Antony Dovgal t...@daylessday.org wrote:
While I fully understand the reasons behind this, I still believe this kind
of thing should be done using the documentation only.
Generating 'educational' notices will just annoy the end users and in 99%
cases they can't do a
On 12 November 2012 21:48, Johannes Schlüter
johannes.schlue...@oracle.com wrote:
On Mon, 2012-11-12 at 21:00 +0800, Adam Harvey wrote:
logical next step is to start generating E_DEPRECATED notices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection
On 12 November 2012 22:01, jpauli jpa...@php.net wrote:
Well, I think we can communicate, then educate people so that they
dont use ext/mysql any more.
It will take the time needed, but if we want this move to come up, we
need to start it. Doing nothing about it, things wont move.
I like
On 13 November 2012 08:44, Christopher Jones
christopher.jo...@oracle.com wrote:
Adam, can you:
1. Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLi
2. Mention how to turn off E_DEPRECATED warnings in the RFC?
When users of 5.5 stumble on the
On 13 November 2012 01:16, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Nov 12, 2012 at 4:00 PM, Ulf Wendel ulf.wen...@oracle.com wrote:
Don't bother. There is a standard way of deprecation, at least I assume
there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove.
I agree to
On 13 November 2012 23:49, Johannes Schlüter johan...@schlueters.de wrote:
Reinis Rozitis r...@roze.lv wrote:
Rewriting perfectly functional mysql code to use mysqli is not a
trivial
move, just as are the problems of re-writing PHP5.2 code to work
cleanly
on 5.4. ISP's are stuck between
On 14 November 2012 00:07, Anthony Ferrara ircmax...@gmail.com wrote:
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal deprecation process. The
problem is that the deprecation process was never designed for a feature
On 15 November 2012 08:36, Devis Lucato de...@lucato.it wrote:
Sorry if this was already suggested before: for people stuck on legacy
applications and without money to upgrade (e.g. charities, user
groups) a PECL extension would at least provide a way to survive.
Forcing people to upgrade
On 16/11/2012 8:58 PM, Patrick ALLAERT patrickalla...@php.net wrote:
2012/11/12 Adam Harvey ahar...@php.net:
Hi everyone,
I've written an RFC to cover deprecating ext/mysql in PHP 5.5:
https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft
deprecation
On 19 November 2012 17:10, Chad Emrys ad...@codeangel.org wrote:
On 11/17/2012 08:54 PM, Adam Harvey wrote:
On 16/11/2012 8:58 PM, Patrick ALLAERT patrickalla...@php.net wrote:
Maybe it is worth mentioning in the RFC what the E_DEPRECATED notice
message would look like so that people hiding
On 19 November 2012 20:44, Anthony Ferrara ircmax...@gmail.com wrote:
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions
On 21 November 2012 13:03, David Muir davidkm...@gmail.com wrote:
On 21/11/12 15:47, Adam Harvey wrote:
2. If we decide not to generate E_DEPRECATED notices in PHP 5.5, what
should the next course of action be:
(a) Enhance the manual text to make the soft deprecation clearer,
and generate
On 21 November 2012 12:47, Adam Harvey ahar...@php.net wrote:
Just to be clear: I don't think that do nothing is a very useful
option for the second question, which is why I've omitted it — it
doesn't seem like anyone's particularly satisfied with the current
state of affairs.
I still think
On 21 November 2012 13:45, Stas Malyshev smalys...@sugarcrm.com wrote:
Proposal: I propose we revert this change. Future consideration might
I see no reason to revert the change and keep dragging around the GUIDs.
Data URLs are much better and cleaner solution, and only reasons not to
do it
On 21 November 2012 14:34, Stas Malyshev smalys...@sugarcrm.com wrote:
it doesn't suit us to. I agree: in practice, I can't imagine anyone
caring a jot about these functions being removed, but we've said that
when we're going to remove something, we'll deprecate for a minor
release, then
All,
I've moved the ext/mysql deprecation RFC into the voting phase. You
can vote at https://wiki.php.net/rfc/mysql_deprecation — note that, as
discussed last week, there are two questions: the first being a simple
yes/no question (which will determine whether the RFC is accepted or
rejected),
On 28 November 2012 14:03, Adam Harvey ahar...@php.net wrote:
big snip, voting open, et cetera
OK, so the first e-mail was the official announcement of voting being
open. I'd now like to quickly lay out why I voted yes, and why I think
it's the right way forward. Feel free to hit next if your
On 29 November 2012 00:36, Anthony Ferrara ircmax...@gmail.com wrote:
However, I'd like to ask you to do something else here. Can you please
update the RFC to reflect the discussions that happened on list? Not
everything that was talked about, but the major discussion points at least.
That way
On 5 December 2012 08:26, Kris Craig kris.cr...@gmail.com wrote:
Seriously, though, 1and1 is a joke. That's not exactly breaking news. If
it really bugs us that much, we could always put up a statement on the
website rebuking their misrepresentation of our version numbering and leak
it to a
All,
I ended up leaving the vote open for a couple of extra days (been a
busy week), but I've now closed the ext/mysql deprecation vote. The
full results are at https://wiki.php.net/rfc/mysql_deprecation — the
short version is that the final vote was 25-12 in favour of
deprecation in PHP 5.5.
On 10 December 2012 18:58, Johannes Schlüter johan...@php.net wrote:
As of this date the 5.3 branch will go to extended support and should
receive security fixes only. Releases will be made based on need.
Please mind that the above schedule is tentative and unpredictable
events might change
On 10 December 2012 20:51, Johannes Schlüter johan...@php.net wrote:
Hi,
On Mon, 2012-12-10 at 20:21 +0800, Adam Harvey wrote:
I'm not suggesting we necessarily extend full support, but I wonder if
one year of critical bug fixes and security updates will be enough.
In my opinion key
On 12 December 2012 04:40, David Soria Parra dso...@gmx.net wrote:
From there I want to go with a new alpha in about two weeks, as we
there are some things like ext/mysql deprecation in the pipeline.
The MySQL commit was pushed yesterday, so that's not a blocker at this point.
Adam
--
PHP
On 18 December 2012 04:52, Lars Strojny l...@strojny.net wrote:
I would go with DateTimeValue or DateTimeImmutable as well.
+1. I'd prefer DateTimeImmutable personally because it describes what
it is better than the other options.
Adam bikeshed Harvey
--
PHP Internals - PHP Runtime
On 21 December 2012 01:26, jpauli jpa...@php.net wrote:
We just tagged PHP 5.5.0alpha2 today. This
release contains bug fixes against alpha1, as well as
new features.
Are we going to have a news post for this on the Web site?
(Alternative question: would you like me to write one?)
Adam
--
On 10 January 2013 03:00, Anthony Ferrara ircmax...@gmail.com wrote:
Well, the point is that there are two ways of voicing your dislike. You can
say I never want this or other rhetoric, which helps nobody else but to
understand that you don't want it. Or you can be a little bit more civil
and
On 10 January 2013 10:05, Tyler Sommer somme...@gmail.com wrote:
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM counterpart Doctrine.
To explain what I meant by PHP, since I think we're arguing
semantics there: I mean
On 12 January 2013 08:17, Ben Ramsey ram...@php.net wrote:
I've opened voting for the array_column() function RFC.
You can vote at https://wiki.php.net/rfc/array_column#voting
To be clear, I've voted -1 solely due to the function alias: if this
were reproposed with either name (I don't have a
On 14 January 2013 17:16, Laruence larue...@php.net wrote:
On Mon, Jan 14, 2013 at 5:11 PM, Pierre Joye pierre@gmail.com wrote:
hi,
I opened the voting phase for the 5.3 EOL RFC.
where is the voting page? :)
https://wiki.php.net/rfc/php53eol
Adam
--
PHP Internals - PHP Runtime
On 30 April 2013 16:15, Rasmus Schultz ras...@mindplay.dk wrote:
At the risk of starting a separate discussion, the recently added
ClassName::class constant provides a way to statically reference a class,
which frankly has very few practical applications in comparison - the need
to reference
On 7 May 2013 09:17, Thomas Anderson zeln...@gmail.com wrote:
It'd be nice if, when doing $objA $objB, that that'd invoke
$objA-__compareTo($objB) or something, much like Java's Comparable
interface.
I wrote https://wiki.php.net/rfc/comparable a couple of years ago —
there's a patch there
On 7 May 2013 12:24, Thomas Anderson zeln...@gmail.com wrote:
I thought half the point of OOP was to abstract away the internals and as
is the error messages don't make much sense unless you *do* consider the
internals.
Like let's say you have a bignum library and you're doing
On 23 May 2013 13:31, Nikita Popov nikita@gmail.com wrote:
On Sat, May 18, 2013 at 11:48 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5.
Once in the hash extension, once in the OpenSSL extension.
The
On 23 May 2013 14:11, Nikita Popov nikita@gmail.com wrote:
If a bug is found we fix it. Proving several implementations of the same
thing to account for potential bugs isn't a good idea imho.
It's not a very good example, I admit, but my point is that it's not
as though they're actually the
On 23 May 2013 17:14, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
the code does throw new, it is always useful. So how you would
propose
to solve this?
rethrow $e;
Yes, this is definitely an option, but requires a new keyword.
We could use a C++ style throw; as an implicit rethrow.
On 24 May 2013 08:26, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, May 24, 2013 at 3:09 PM, Nikita Popov nikita@gmail.com wrote:
We already have a lot of functions for multibyte string handling. Let me
list a few:
* The str* functions. Most of them are safe for usage with UTF8.
On 26 May 2013 21:05, Stas Malyshev smalys...@sugarcrm.com wrote:
I agree with Nikita — I'm not against adding more Unicode/charset
handling functions if they make sense (and I haven't looked at the
code for this particular proposal yet), particularly if they'd be part
of a default build, but
On 20 June 2013 14:36, Julien Pauli jpa...@php.net wrote:
On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote:
Hi all,
As you know, 5.5 final is coming soon.
We are in RC, so mainly stabilizing stuff and preparing the final release
for anyone to setup 5.5 on their servers.
(Piggy-backing on Sara's e-mail, although this is more a response to
Sherif and Yasuo.)
On 19 July 2013 22:33, Sara Golemon poll...@php.net wrote:
I never said that the compiler might magically produce differing results
for the same input. I said that the language's definition does not declare
On 21 July 2011 02:19, Pierre Joye pierre@gmail.com wrote:
Now the only question remaining is which level warning we should use
for the setter. I'm happy with E_CORE. Objections?
None here. +1 for E_CORE_ERROR — it's exactly what it's for.
Adam
--
PHP Internals - PHP Runtime Development
On 22 July 2011 09:12, Alex Howansky alex.howan...@gmail.com wrote:
That makes sense if it would overwrite the methods as well, but
otherwise it seems like it provides inconsistent functionality.
Exactly. At the least, it's inconsistent. If it's a bug, then it seems the
question becomes:
On Jul 23, 2011 2:51 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Now that we've decided to add E_STRICT to E_ALL error mask, the question
is - what should we put in recommended production INI - should we include
E_STRICT or not?
Development has E_STRICT anyway, so no question there.
I can't
On Aug 2, 2011 2:50 AM, Hannes Landeholm landeh...@gmail.com wrote:
aharvey: I'm surprised you voted no since you seemed content with the
answers you got earlier. Do you have some special objection in mind?
Sorry, I meant to send an e-mail last night explaining the -1 and
completely forgot
On 12 August 2011 18:26, Derick Rethans der...@php.net wrote:
I share Richard's concerns about finding out what is the real one/best
one/latest one.
I didn't understand the problem when Richard first posted, and I still
don't now, to be honest. The canonical repository is the one the
php.net
On Aug 20, 2011 7:19 PM, Pierre Joye pierre@gmail.com wrote:
On Sat, Aug 20, 2011 at 11:16 AM, Scott MacVicar sc...@macvicar.net
wrote:
5.3.8 and lets not apply the coverity fixes during the final RC.
Let not apply anything before the final RC. That's how it should be.
Seconded.
On 23 August 2011 15:16, Chad Emrys ad...@codeangel.org wrote:
I emailed here because I'm afraid no one will notice the bug in time for
this 5.3.8 release you may be releasing for the crypt() fix:
I'm not sure I'd class this one as mission critical, but it's fixed, anyway. :)
Adam
--
PHP
On 9 November 2011 22:44, Peter Cowburn petercowb...@gmail.com wrote:
I am removing my vote due to a particularly annoying aspect of this
whole RFC/voting structure: the RFC is still in flux!
This is one of the reasons why I've voted -1: there's no way an RFC
should be changing this much (or at
(Resurrecting a very old thread. Sorry about the thread necromancy.)
On 8 September 2011 05:20, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 09/07/2011 02:12 PM, Stas Malyshev wrote:
But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
itimer implementation at least up to
On 3 February 2012 12:05, Stas Malyshev smalys...@sugarcrm.com wrote:
For me at least, tests/func/005a.phpt is the last failing test on
PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
pre-5.4.0 to help get cleaner test suite results.
I really wouldn't want to hold the
On 6 February 2012 04:37, Tom Boutell t...@punkave.com wrote:
Deprecate and then remove, or just leave it in. Make it optional
forever just generates more nonportable PHP code. Ick.
Huge +1 to that.
Given the existence of preg_replace_callback() (as Stas noted above),
my preference is for
On 3 February 2012 12:15, Adam Harvey ahar...@php.net wrote:
On 3 February 2012 12:05, Stas Malyshev smalys...@sugarcrm.com wrote:
For me at least, tests/func/005a.phpt is the last failing test on
PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
pre-5.4.0 to help get
On 8 February 2012 04:09, Stas Malyshev smalys...@sugarcrm.com wrote:
Specifically, how about the attached patch (also available at
http://www.adamharvey.name/patches/osx-max_execution_time-test-patch.diff,
in case the mailing list decides to strip it)? This only patches the
test to XFAIL this
On 17 February 2012 18:54, Ondřej Surý ond...@sury.org wrote:
Little nag (with patch) to not forget to update 5.3.11 changelog with
5.3.10 changes.
The patch doesn't appear to have made it, but I've merged the 5.3.10
NEWS into the PHP_5_3 NEWS. Thanks for the reminder. :)
Adam
--
PHP
On 25 February 2012 04:02, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Fri, 24 Feb 2012 20:57:50 +0100, Stas Malyshev smalys...@sugarcrm.com
wrote:
If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
included? This would reduce any negative user sentiment that PHP 5.4
Hi all,
Google are running the Summer of Code again this year, and Dan Brown
and I have tentatively agreed to act as organisation administrators if
we can get an application together. We have a week from today to
apply, but before we can, we need updated ideas. Our old ideas list is
at
On 2 March 2012 10:00, Adam Harvey ahar...@php.net wrote:
Google are running the Summer of Code again this year, and Dan Brown
and I have tentatively agreed to act as organisation administrators if
we can get an application together. We have a week from today to
apply, but before we can, we
On 2 March 2012 09:56, Philip Olson phi...@roshambo.org wrote:
Please clarify whether or not get_magic_quotes_gpc() and
get_magic_quotes_runtime()
are deprecated, because I do not think they are. Deprecated means people
should not
use them while writing new code, but they are perfectly
On 2 March 2012 21:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
Fair enough. Option #1 seems the most appropriate then. The others seem too
drastic to implement with such short notice.
+1. We can't drop bug fixes immediately without warning, and I don't
think the overhead of backporting
On 2 March 2012 21:34, Simon Schick simonsimc...@googlemail.com wrote:
One or two years is way to short if you'd ask me. A major release should be
supported with all kind of bug fixes for min. 3 years after a new release
has been brought out. Specially if it's a wide-spread language like PHP
On 9 March 2012 00:11, Remi Collet r...@fedoraproject.org wrote:
Le 08/03/2012 09:03, Michael Wallner a écrit :
Sorry for the delay, but I already explained the issue in
the bug report: https://bugs.php.net/bug.php?id=61291
Thanks, for the explanation.
I'm still concerned about the idea that
On 27 March 2012 09:55, Yasuo Ohgaki yohg...@ohgaki.net wrote:
http://www.php.net/mailing-lists.php
At the bottom of this page, http://www.ezmlm.org/ is refereed.
However, it seems this domain is dead.
It looks like the domain has expired. Along with probably ten thousand
other people, I'll
On 3 April 2012 09:46, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 04/02/2012 06:35 PM, Charlie Somerville wrote:
I've created a pull request (https://github.com/php/php-src/pull/33) that
changes json_encode to fall back to ASCII for strings that are not valid
UTF-8.
I ran into an issue in
On 4 April 2012 10:02, Alan Knowles a...@akbkhome.com wrote:
PHP enforces rules like $this can not be used in a method marked 'static'.
So why not flag methods (and internal functions) with a flag that indicates
they can throw things. Since PHP is not a compiled language we can not pick
up
On 17 April 2012 11:42, sle...@pipeline.com wrote:
Just b/c there are rarely any women at all that participate on this list,
could we at list maintain a facade of gender neutrality? I seriously can't
believe that you used the word him. What about her? Yeah, her as in
myself and every
On 18 April 2012 06:40, Kris Craig kris.cr...@gmail.com wrote:
Forgive me if this has been addressed before, but I was wondering: Have we
ever considered maintaining an RPM for PHP dependencies for each version
branch? The are legitimate reasons why people prefer to build PHP manually
On 18 April 2012 06:54, Stas Malyshev smalys...@sugarcrm.com wrote:
create_query(deleted=0, name,,, /*report_errors*/ true);
I like it. At the risk of bikeshedding, can we have a token rather
than just a series of commas — say reusing the default keyword so it
would look like this instead:
I'm a developer on pear/Auth and pear/Config.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 17 March 2010 16:50, Jan Schneider j...@horde.org wrote:
How about 5.3.99? A lot of projects use this for pre-releases, but it still
might make sense.
I'm wary of sticking with anything starting with 5.3 if we're going to
break binary compatibility on the new trunk (which we presumably are)
As at least some of you would already be aware, there's a
long-standing issue with using PHP in a Turkish or Azeri locale,
namely that case-insensitive lookups within the Zend engine (method
names, for example) fail on lookups involving upper-case I characters,
since lower-case I in those
On 19 April 2010 12:59, Stan Vassilev sv_for...@fmethod.com wrote:
If you ask me, there's only one way to fix this, which is how most other
languages fixed it: make the next major version of PHP case-sensitive for
all identifiers. For less bugs, less locale problems and more performance.
Hi Mats,
On 20 April 2010 00:18, Mats Lindh mats.li...@gmail.com wrote:
The filter_input function has an errornous check for the
FILTER_NULL_ON_FAILURE flag, where it returns NULL if it is NOT set,
and not if it is set.
I added the patch to the bug tracker over a week ago, but it seems
like
On 29 April 2010 23:16, Ionut G. Stan ionut.g.s...@gmail.com wrote:
##php on freenode: http://freenode.net/irc_servers.shtml
The double pound (##) means that it's not official.
It's probably worth noting that ##php is much more a help channel than
a general discussion channel, although that's
2010/4/30 Gwynne Raskind gwy...@darkrainfall.org:
On Apr 29, 2010, at 10:05 AM, Lukas Kahwe Smith wrote:
As I've mentioned in the past I think we are better off with shorter
release cycles and less features per cycle. Reduces risk and enables us to
push out value faster. For example, we have
On 19 April 2010 11:58, Adam Harvey ahar...@php.net wrote:
As at least some of you would already be aware, there's a
long-standing issue with using PHP in a Turkish or Azeri locale,
namely that case-insensitive lookups within the Zend engine (method
names, for example) fail on lookups
On 4 May 2010 20:14, Adam Harvey ahar...@php.net wrote:
If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up
the votes in a week or so. And yes, I am volunteering to deal with
this should option 1 or 2 be picked.
Separate e-mail for housekeeping purposes: my vote
On 5 May 2010 19:01, Steven Van Poeck svanpo...@gmail.com wrote:
Right. That's what I meant by inconsistent code. The call
$logs-getSQLLogger()-logSql(...) would function I presume.
The reason your example code does not is because it is inconsistent. You're
calling $logs-getSqlLogger() instead
On 12 May 2010 06:01, Sara Golemon poll...@php.net wrote:
On method naming, I was following the pattern of __*() for always on magic
methods (__get(), __set(), etc...) versus interface-induced magic methods
(offsetGet(), offsetSet(), etc...).
Agreed. I don't have any real preference on the
On 24 May 2010 13:09, Zeev Suraski z...@zend.com wrote:
I see three key options going forward:
1. Implement the table along the lines of what it looks like now, perhaps
with minor changes.
2. Implement identical conversion rules to the ones that exist in PHP; That
effectively turns type
2010/5/28 Johannes Schlüter johan...@schlueters.de:
Is anybody using this file? If this is thee case could somebody then
make sure it's being updated (and maybe take care of
ChangeLog-200[6-9].gz being created) else I'd suggest dropping them. An
outdated file might be confusing for users
2010/6/1 Johannes Schlüter johan...@schlueters.de:
On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote:
I think make no sense to keep it deprecated.
Here's a patch for undeprecate ext/ereg in 5_3 and trunk:
http://felipe.ath.cx/diff/undeprecate-ereg.diff
Any objection? If no, I'll commit
On 15 June 2010 19:41, Ilia Alshanetsky i...@prohost.org wrote:
After speaking to a few developers in DPC, I think it makes sense for us to
drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3
extensions. The sqlite2 library is no longer maintainer and the migration
On 13 July 2010 23:12, Ferenc Kovacs i...@tyrael.hu wrote:
http://bugs.php.net/50255
jani tends to close bugs without much reading.
Honestly, Jani's... uh, unique approach was a large part of why I've
tried to get a little more involved in bug triage work in the last
year. The point is that
1 - 100 of 231 matches
Mail list logo
