RE: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
On November-23-11 5:31 PM Gustavo Lopes wrote: On Wed, 23 Nov 2011 21:06:09 -, Pierre Joye pierre@gmail.com wrote: The fact that we have reports here showing code not working anymore because of this change tells me that it is a BC break. We can call it a bug fix but it still breaks code out there for no real benefit but edge case usages. We had this situation before, that does not help us. I'd say for no benefit at all. Why would anyone ever want to take a string offset from a string that certainly has length 1? Except for taking satisfaction in this improved consistency, I see absolutely no benefit. Up until now, it was deemed a useless but innocuous change. Now that we found it has pernicious side effects, we ought to revert it. Notwithstanding that this behaviour was possible because of a bug, it has admittedly been relied on since time immemorial, making it a significant BC break. As distasteful as it seems, it absolutely should be reverted IMHO. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] enable mbstring by default
On October-11-11 11:46 AM Ferenc Kovacs wrote: As the full unicode support went down with php6, wouldn't it be a logical step to enable the mbstring extension by default(maybe even turning it into a builtin ext like phar)? I think that mbstring is a pretty mature and stable extension, and there isn't much dependencies so I can't think of reason why we couldn't do it. Of course the mbstring.func_overload would still disabled by default (maybe exporting the mb functions to the 'utf8' namespace? :P), so it would be a backward compatible change. What do you think? ps: maybe it is too late for 5.4, but having it in trunk is still better than nothing. The mbstring extension was enabled by default once upon a time, if memory serves, and as I recall the results were extremely painful. While both PHP and mbstring have matured significantly since then, I'm old school that way. Fool me once... Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Autotests: Access denied for user 'root'@'localhost' (using password: NO)
On August-17-11 8:04 PM Roger Llopart Pla wrote: That use, or, if it's a development machine, leave it as it is since it does it's work just fine. 2011/8/18 Reindl Harald h.rei...@thelounge.net Am 18.08.2011 01:30, schrieb Stas Malyshev: Hi! well but using root as default is a little bit crazy using user test with empty password is acceptable but root It's not _that_ root. For mysql, it's just a default user name. Most people would run it on development machines with mysql configured not to answer to network, so it's not of a problem it IS THAT root of mysql please do not believe i think it has anything to do with system-root i am doing this job now since ten years :-) using a build/test-server with mysql-driven pure-ftpd and phpmyadmin while having horde-webmail also on the test-machine and you are f**ed with a mysql-root without password the only sense for the default-root without pwd in mysql is to enter mysql -u root and set your pwd directly after install It strikes me that the out-of-the-box test only works on a fresh clean install of MySQL. The install docs for MySQL strongly recommend changing that immediately after the install - which I think most people do - so I doubt very much those are the credentials for the vast majority of MySQL installs in the world. I'm wondering if adding a prompt for the mysql username and password, with the defaults set as is, would be possible, and if so, if someone were to offer a patch why it shouldn't be considered. IMHO, if the defaults were used and the tests ran successfully, I'd be tempted to display a console message along the lines of your myself default root credentials are wide open, are you being silly? Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] deprecating ext/mysql
On July-11-11 Matthew Weier O'Phinney wrote: Sent: July-11-11 1:57 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] deprecating ext/mysql On 2011-07-11, Paul Dragoonis Yes, +1 from me too. I do indeed think we need to make this a smooth transition over time. Possibly triggering an E_DEPRECATED for all ext/mysql usage. Just like the introduction of E_DEPRECATED for 5.3 functions, we could apply the same approach here. After 5.4 is released we can put big Deprecated Warning notifications on all php.net/mysql_* functions too. I think we all want this, but to be realistic from a production point of view, many sites will still be using ext/mysql. And, to my reading, this is exactly the path that was recommended. The point is to start a soft deprecation now via the manual, indicating that users should migrate to other solutions, while simultaneously detailing how to do equivalent operations via ext/mysqli or pdo_mysql. Actual deprecation would happen later. I haven't looked at the mysql_* section of the manual in 15 years. It would not surprise me to learn that that was one of the least viewed areas of manual. I'd be curious to see what kind of response this suggestion would elicit from the PHP General list. From the MySQL site: We have no plans to remove libmysql support from ext/mysql, ext/mysqli or PDO_MYSQL, which would break existing applications. We just add a new, superior alternative to our PHP offerings. So I'd also be interested to hear what the MySQL folks had to say about this. If a laissez-faire approach is taken a lot of people are going to have bite marks on their behinds. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] deprecating ext/mysql
On July-10-11 1:16 PM Reindl Harald wrote: Am 10.07.2011 19:03, schrieb Philip Olson: What this means to ext/mysql: - Softly deprecate ext/mysql with education (docs) starting today - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0 - Add pdo_mysql examples within the ext/mysql docs that mimic the - current examples, but occasionally introduce features like - prepared statements - Focus energy on cleaning up the pdo_mysql and mysqli documentation - Create a general The MySQL situation document that explains the - situation The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users sounds reasonable and i would love to be not forced loading mysql.so AND mysqli.so because some peopole are using legacy code and unwilling to maintain their stuff Sure, some users in the PHP community are aware of this desire. We're talking about tons of developers, vast amounts of legacy code written over 2 decades - longer than many in that same community have been alive. Most developers out there are not remotely aware of this. IMHO, it doesn't matter how early the education gets started or how much time and sugar is used to coat this, it'll be a bitter pill for a very large group of people. This needs to be thought out very carefully. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] preg_match
On July-08-11 10:01 AM Rafael Dohms wrote: [snip] first time using preg_match is a nightmare. IMHO, preg_match is poetry in motion. Going through a million lines of code replacing ereg[i] with preg_match because it was deprecated in 5.3 - *that* is a nightmare. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] -W option for CLI strict mode
On July-06-11 12:58 AM Adam Harvey wrote: On 6 July 2011 06:00, Richard Quadling rquadl...@gmail.com wrote: I'd also add in the display_startup_errors to this also. As I see it, the idea is to make things as noisy or as quiet as possible. Agreed. That was an oversight on my part. I'll update the patches to handle that as well. Nice. I have use for this. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] -W option for CLI strict mode
On July-06-11 11:49 AM Peter Cowburn [mailto:petercowb...@gmail.com] On 6 July 2011 16:04, Richard Quadling rquadl...@gmail.com wrote: What happens of both LOUD and quiet are used. Personally, I'd say this is an error and abort. An error, and abort silently. :) Whatever the consensus is. :) The devil's in the details of course (and that's easy for me to say since I'm not doing the work). But overall I'd say this is a nice, simple, useful feature. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 alpha
On June-28-11 2:06 PM Stas Malyshev wrote: On 6/28/11 10:43 AM, Pierre Joye wrote: I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. Really, guys, if we ever want to have scheduled and orderly releases, changing release schedule in the last minute repeatedly and repackaging in the last second is exactly NOT the way to do it. IMHO, exactly right. Not much point in having a plan if it isn't followed, and that usually ends up causing problems - what the plan is supposed to prevent. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 again
May-10-11 11:57 AM Matthew Weier O'Phinney wrote: A native docblock annotation parser would much better suit our purposes. +1, FWIW. So, basically, we're in a situation where there's no consensus on whether the feature is needed or what the approach should be, and people pointing fingers at eachother indicating the other party is not listening or providing constructive feedback. I think that's reason enough to pan the feature for 5.4. Humbly, I agree. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] proposed access modifier silent ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
On Mon, Apr 11, 2011 at 4:09 PM Chris Stockton wrote: My suggestion to use ?? I will say has little to do with laziness. I would be happy with any solution that solves my problem, I just know that implementing a patch for ?? would be simple enough (I could even do so if requested). Everyone has different use patterns as shown in other examples, this is natural and just comes with the domain. Laziness should not be confused with a desire to write clean readable code quickly. :) I have use for this, it's a nice clean solution to a simple problem. FWIW, +1. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP] [security] PHP has DoS vuln with large decimal points
On 2011-01-16, at 9:59 PM, Daniel Brown danbr...@php.net wrote:
On Sun, Jan 16, 2011 at 21:00, Tommy Pham tommy...@gmail.com wrote:
Here are the results after some further tests for the same platform:
* max float value: 1.7976931348623E+308
* min float value: 9.8813129168249E-324
floatval('1.00e-323') weird ...
PHP wil hang when the value is between (inclusive)
floatval('2.22507385850720102e-308') -
floatval('2.22507385850720113e-308')
I can't find the bug report for the issue @ bugs.php.net. Does anyone know
if one is submitted? I should submit one? Sucribe to dev list and go from
there?
If in doubt, file a bug. Worse comes to worst, it will be marked
as bogus or a duplicate. For security-related things, send them to
secur...@php.net, not to the General list. Again, if it's of no
concern, it will simply be ignored as bogus or already known
Is this not it?
http://bugs.php.net/53632
Best Regards
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Add option to disable POST data processing
December-18-10 12:07 PM Daniel Convissor wrote: Completely disabling POST is something that is probably best done via web server configurations. Doing this at the applicaiton/programming layer seems like a kludge. No offence, but I'm still waiting for someone with 2 breadsticks stuck up their nose to jump out and yell April Fools. :) Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] new foo()-bar()
November-26-10 2:36 PM, Felipe Pena writes:
Hi all,
I'm here again to presents another proposal, which adds support for
instantiating a class and calling its methods and accessing its
properties on same command.
Example:
?php
class bar {
public $x = 'PHP';
}
class foo extends bar {
public function bar() {
return $this;
}
}
var_dump(new foo()-bar()-x); // string(3) PHP
?
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
Nice. I have use for this.
Some readability issues may arise but nothing that can't be
overcome with some common sense.
Best Regards,
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Magic quotes in trunk
On November-17-10 11:09 AM Kalle Sommer Nielsen wrote:
Greetings
I wanted to raise this topic before we go Alpha with trunk, regarding
our beloved magic_quotes feature. There seems to be mixed opinions
regarding it so I thought I would take it up for discussion.
We have advised people not to use magic_quotes, register_globals and
the like for years, and they were marked as deprecated in 5.3.0+ if
activated through their php.ini directives. Yet magic_quotes still is
set to On in 5.3.0. I think its worth we either remove the feature
or disable it in trunk as its a security related feature. Lets have a
look at what each of those options means:
Removing magic_quotes):
Means we will remove the feature entirely in the source, we will throw
an E_CORE_ERROR if activated so people who have it enabled are forced
to disable it and make their applications work without magic_quotes.
This creates a minor issue for the hosts that simply disable it and
have their customers applications run without them which can create a
security risk for them, although it should be fairly limited. The
functions to check for magic_quotes_runtime should however stay for BC
to avoid applications that run on multiple versions of PHP from doing:
if(function_exists('...') ...)
Disabling them):
This will help to disable the spread of magic_quotes even more, and it
can safely be removed in the next major version of PHP.
My personal vote here goes towards removing them entirely.
What are your inputs on this matter?
IMHO, removing magic_quotes should be done only in the next major version.
Far too many people are going to get bit on the behind by this type of
change in a minor version. I do agree it needs to crash and burn, but I
think it'll take millions of lines of code down with it (sadly).
To me, removing it and disabling it by default are practically speaking
the same thing. So the same applies - next major version.
If by consensus the group should decide to go ahead anyway, I would suggest
a big fat notice with the release announcement and a prominent spot on the
front page of php.net (now?), and perhaps consider bumping the version
number
up 1 (to 5.5?) just to get people's attention. This is huge.
Best Regards,
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
November-16-10 2:21 AM - Zeev Suraski wrote: Like I said – of course annotations bring value. If that was the only property when evaluating a new feature to be added, PHP would very quickly become an everything-and-the-kitchen-sink language. Thankfully, it’s not. Amen. -1 Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 Alpha?
On Tue, Aug 10 2010, Derick Rethans wrote On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote: With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. I'd say: let's do 5.4-alpha! There's plenty of cool stuff in trunk. Absolutely. Humbly, if the release early, release often mantra is to be [re-]embraced, I'd say start right now. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Remove sqlite2 from trunk
On June-17-10 5:23 AM Derick Rethans wrote: On Tue, 15 Jun 2010, Patrick ALLAERT wrote: What about doing the same with MySQL extensions ? Currently there is 3 main ways to access a MySQL server: ext/mysql ext/mysqli PDO_MYSQL Additionally, mysqlnd has to be considered as a possible library for each of them. I have the feeling that there is a benefit at removing ext/mysql with the same arguments as for sqlite 2. I would be against that. Derick = sigh of relief = The voice of reason. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Remove sqlite2 from trunk
On June-17-10 12:44 PM Pierre Joye wrote: Sent: June-17-10 12:44 PM To: Mike Robinson Cc: Derick Rethans; Patrick ALLAERT; Ilia Alshanetsky; Adam Harvey; internals@lists.php.net Subject: Re: [PHP-DEV] Remove sqlite2 from trunk On Thu, Jun 17, 2010 at 5:12 PM, Mike Robinson m...@rile.ca wrote: On June-17-10 5:23 AM Derick Rethans wrote: On Tue, 15 Jun 2010, Patrick ALLAERT wrote: What about doing the same with MySQL extensions ? Currently there is 3 main ways to access a MySQL server: ext/mysql ext/mysqli PDO_MYSQL Additionally, mysqlnd has to be considered as a possible library for each of them. I have the feeling that there is a benefit at removing ext/mysql with the same arguments as for sqlite 2. I would be against that. Derick = sigh of relief = The voice of reason. The only voice that matters here is the voice of the mysql team, they know if it is still widely used or not, and how :) Really? Seriously, how could they reliably know that? :) I still like the I would be against that, notwithstanding. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Removal of deprecated features
Hi, Respectfully, FWIW... safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_ca ll_time_pass_reference +1 asp_tags - Proposed to be removed aswell, Tony had a patch for this[5]. -1 No way. While I abhor there use, _many_ people do not. sql_safe_mode - Theres currently an RFC in the works about this by Johannes[6]. +1 session_register/session_is_registered/session_register - Only needed for register_globals, Hannes removed those in PHP6. +1 enable_dl - Is this really worth keeping, since dl() was disabled on almost all SAPIs except for CLI/CGI/Embed? +1 Support for Freetype 1 and GD 1 - Removed by Pierre in PHP6 +1 (With my sincere gratitude to Thomas for his work all those years) Class named constructors -1 Not in 5.x - the BC break here is huge. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Closures and $this: Please vote!
Christian Seiler wrote Hi Lukas, Call for a vote. This time around people cannot claim to not have had time to review the issue. Also back then we tried to play it safe because of the short time before we were to release. This time there is more time for this to mature if needed inside svn. Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) (A): Original closures implementation: $this is always the object context at closure creation. No possibility to do $someObject-closureProperty(...) and thus no possibility to extend objects! (C): Javascript-like behaviour: Bind $this only when calling the closure as object method, else $this is undefined. (D): JS-like behaviour on top of (A). Please look at the RFC as to why I consider it to be a *REALLY*, *REALLY* bad idea. (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) My vote: (A+) Regards, Christian FWIW, another non-internal-dev vote for (A+). Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] display_errors = on
Hannes Magnusson wrote: I am totally against this change for 5.2. 5.3 on the otherhand should definitely make this finally happen. Very reasonable - the best approach I would think. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] keeping traffic on this list manageable
Lukas Kahwe Smith wrote: We do have something along those lines: http://www.php.net/reST/php-src/README.MAILINGLIST_RULES Maybe it needs to be cut down (or just provide the key points at the top) and automatically appended to all emails (including the welcome email) .. There you have it. A dozen years on the list and I didn't even know that file existed. I'll bet there are many, many others. Brilliant idea adding a condensed version to the welcome emails and appending it onto all outgoing emails, maybe with a link back to the rules document above. It'll go a long way to decreasing noise. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.3 Suggested Feature List
Hey Steph, PECL, right. Ilia's initial post mentioned possibly enabling them by default which set off some red flags for me because it's very much alpha. It'd definitely help things along if it goes into the core, in terms of exposure / usage / testing. Best, Mike Robinson -Original Message- From: Steph Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 6:40 PM To: Mike Robinson; 'Ilia Alshanetsky'; 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature List Hi Mike, 7) Introduce mysqlind library into core and use it as a backend for PDO and mysqli extensions (possibly enabling them by default) 1 0 -1 The mysqlind driver is currently alpha. Wherever it goes it should be marked EXPERIMENTAL and off by default Frankly, I'm wondering (out loud) if PEAR wouldn't be a better place for it until PHP6? ouf PEAR is for PHP code, PECL is for C code. This is C code. It's also a *native* PHP driver, meaning it's faster than the libmysql library used currently for all MySQL-related extensions. The difference in build terms is simply a configure switch, and I don't see anyone recommending it should be mysqlnd by default at this stage. - Steph No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.15/1002 - Release Date: 9/11/2007 5:46 PM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.3 Suggested Feature List
Since my vote counts for shyte, I'll humbly offer brief remarks instead. Ilia Alshanetsky queried: 6) Remove safe_mode, register_globals and magic_quotes 1 0 -1 *Major* BC break in a minor version? Ouch. This should wait I think. 7) Introduce mysqlind library into core and use it as a backend for PDO and mysqli extensions (possibly enabling them by default) 1 0 -1 The mysqlind driver is currently alpha. Wherever it goes it should be marked EXPERIMENTAL and off by default Frankly, I'm wondering (out loud) if PEAR wouldn't be a better place for it until PHP6? Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] POSIX regex
Jani Taskinen writes: On Thu, 2007-07-19 at 15:39 -0700, Andrei Zmievski wrote: Python did go down that road, but take a look at Python 3000 effort and you will see that what they are trying to do is exactly what we have: native Unicode strings, without prefixes. So maybe we should learn from mistakes other have already made and not do the same.. and remove that stupid option before it's too late. You betcha! IMHO, it'll be a persistent ugliness and source of headaches and regret for a long time. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RIP PHP 4?
Derick Rethans said: Ladies, Gentlemen, Kings and Princesses, With the nice PHP 5 / PHP 6 unicode semantics thread under way I am trying to gauge what people feel about dropping support for PHP 4 at the end of this year. That does not mean that we will not fix security issues, we have to as the install base is too large, but that would be the only thing that would warrant a new release. I already sort of mentioned this on april 1st, but I think we should come with a slightly more official statement. Your votes please (only -1 and +1 are allowed)! +1, served me well, RIP... Amen. Best regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Derick Rethans wrote: Jeremy Privett wrote: I actually don't have a problem with 95% of PHP 6 installations turning off Unicode support and this being the default setting for ISP's. I do, because that will end up in less hosts running with real unicode support. They can always tell their clients we have php 6 - while it is in fact just the crippled non-unicode version of it. IMHO, how many hosts that run PHP6 with unicode support is moot - as long as those who need it get it and those that don't aren't penalized by having their PHP6 install crippled turning off unicode. Just the notion that disabling unicode somehow cripples PHP6 is quite startling. That aside, it seems to me that PHP5 support will be around for a while. People can take that time to learn. Some of the energy saved supporting this setting and it's underlying needs can be better devoted to some documentation for teaching people how to migrate to a unicode-aware programming world. FWIW then, do it now. Cut the cord. Remove the setting and be done with it. Frankly, I think the PHP team has done far too much hand-holding and coddling in the last few years (an admirable, very under-appreciated job I might add). I think the core team will have its hands full getting PHP6 out the door and keeping PHP5 reasonably maintained. Humbly, I believe adding unicode.semantics to the equation may be a heavy, heavy piece of straw that breaks a lot of backs. Joe User included. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
It could well be the last chance to get the mail() logger into 5.x as well, and IMHO a lot of people are waiting for this that can't/won't migrate to PHP6 quickly. Best, Mike Robinson Ilia Alshanetsky writes: IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.1 twice as slow?
Andrew Hutchings writes I dunno what the heck I am doing wrong then :) I have tried on a PPC running OSX, a Xen host on a Dual Xeon running Ubuntu Edgy, an EPIA running Ubuntu Edgy and the Xeon devel box. When configuring with ./configure --disable-all --disable-cgi and compiling with no additional CFLAGS on all those machines the benchmarks actually work out almost the same but in every case strcat is a lot slower on 5.2.1. I'm guessing the rest of the slowness is something to do with my configuration options. I've run the bench on a development box at work. A hefty box with no load, running Fedora Core 5. The strcat results were approximately *10 times slower* on 5.2.1 than on 5.2.0. Everything else was nominal. So I reran the bench on my dev box at home. Same deal. The overall result was close (hence my previous comments), but strcat was about 9 times slower on 5.2.1 than 5.2.0. One of my guys at work ran the bench on his Gentoo box against 5.1.16. Same deal, strcat *way* slower on 5.2.1 than 5.1.16. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.1 twice as slow?
Stanislav Malyshev wrote: I tried to run test on my machine, could not reproduce the effect. I've run the bench script on my Redhat-FC6 box with 5.2.0 and 5.2.1, configs exactly the same. I could not reproduce the effect either. [phew] Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Syntactic improvement to array
Richard Lynch wrote:
More edge cases:
$foo = array(1, 2, 3];
$bar = [1, 2, 3);
Syntax error because it's unbalancedO
Or kosher, because the choice of start/end delimiters should
be up to the user?
Should it match whatever rule is in place for:
if (...){
endif;
echo(foo.inc);
echo foo.inc;
$foo = array(1,2,3);
$foo = [1,2,3];
echo $foo[0];
echo $foo{0};
$foo = [1,2,3); // parse error
echo(foo.inc; // parse error
Come on. This isn't rocket science, even for newcomers.
It certainly isn't worthy of the [awesome] level of analysis it's getting.
Holy smokes.
Best,
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Syntactic improvement to array
Pierre wrote: On 2/4/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote: I personally find array extremely clear, in recent weeks I had to do A LOT of JavaScript work where the array syntax works in a manner you suggest for PHP and its a massive pain. It does not make for a very clear code. I think the syntax you propose is extremely confusing and we should stick to what we have right now. If someone does not like this new syntax, he can stick to array(). It is in no way an argument to refuse the new syntax addition. I agree sir. It's a nice little addition - all the better if it isn't too much work to implement and someone has already volunteered to do it. :) Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mail() logging for PHP
Ilia Alshanetsky writes: Is there any interest in adding support for logging of mail() calls and/or adding options that allow identification of who sent the e-mail. I've wrote a quick patch that enables this functionality via two ini settings controllable via php.ini or per-virtual host. The first option, mail.add_x_header (boolean) allows you to enable the addition of the X-PHP-Originating-Script header to each mail sent by mail(), which will include the uid of the script and its name. The combination of the two should be sufficient to identify the user to whom the script belongs and via a simple find command locate the actual script. This option is intended primarily for instances where you have a bounced e-mail or a forwarded mail with a spam complaint, allowing you to quickly identify the offender. The second option, mail.log (takes a filename) allows you to enable logging of every single mail() call, each log line will include the fullpath of the file and the line where the mail() was called from in addition to the To address and any headers (to keep track of CC, BCC) that were part of the function call. To ensure that each log line is 1 line long, \r and \n are replaced with spaces. The patch that makes this possible can be found here: http://ilia.ws/uploads/patches/mail_log.txt.gz Ilia Alshanetsky A fabulous addition. How fast can this make it into PHP? 5.2.1? 8-) Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Congrats, and thanks
To all, Congratulations on the release of 5.2 folks. Once again, I wish to express my sincere gratitude to the PHP team, dev and docs, for their hard work, dedication and perseverance in maintaining and advancing this magnificent language. Not to mention your incredible patience. :) You continue to show the way, and shine a light on the open source world. I can't imagine my toolbox without PHP. Standing ovation, and my deepest thanks, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [RFC] E_DEPRECATED
I myself wrote: Christian Schneider writes: Another idea (I haven't seen skimming through the replies): Move use of undefined variable, property and index from E_NOTICE to E_STRICT as it is a coding style question some people use to find typos. IMHO it's more than just a coding style used to find typos. It's one of the *nicest* features PHP ever had, and it's a bloody shame it's gone. Sorry guys, I (thankfully) misunderstood. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [RFC] E_DEPRECATED
Christian Schneider writes: Another idea (I haven't seen skimming through the replies): Move use of undefined variable, property and index from E_NOTICE to E_STRICT as it is a coding style question some people use to find typos. IMHO it's more than just a coding style used to find typos. It's one of the *nicest* features PHP ever had, and it's a bloody shame it's gone. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Filter Vote
On Thursday, September 28, 2006 at 7:52 PM Ilia Alshanetsky wrote: A good deal of time has passed and it seems Derick and Pierre are no closer to the consensus about the filter extension and in the meantime 5.2 release process is stalling. At this point I think as the Release Manager I need make a decision on how to proceed. Before I make a decision I'd like to hear some feedback from other developers and users of PHP on what they think. The current options are: [ ] Indefinitely delay 5.2 release until filter issue can be resolved. [ ] Remove filter from PHP 5.2 and hope that some near-future release will re-introduce it [ ] Go with what we have right now, and if filter developers want to make changes they'll need to do so in a manner backwards compatible to the current code. Personally, I'd prefer to take filter out entirely from the 5.2 tree. If the filter extension goes in now and remains marked 'experimental', making changes that break BC is moot - that's why it's marked experimental and the docs explain that _very_ clearly - things can and probably will change. IMHO, it should go in as is and the 5.2 cycle resumed and completed. If the guys needed another few days to arrive at a concensus I would consider that a fair price to pay in order to mitigate BC breaks in the future, but that additional delay would be at your discretion of course. Best Regards Mike Robinson -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.9/458 - Release Date: 9/27/2006 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] kudos
Once again, I would like to extend my sincere, profound gratitude to the PHP Development Team for the continued effort in making and keeping PHP the extraordinary tool that it is. The amount of work that has gone into the release of PHP-5.x is enormous. The changelog for the latest versions could occupy a chapter in anyone's next PHP book. It probably should, as a testament to the dedication of several remarkable individuals, and of course the 'countless others' whose hard work and expertise often go unrecognized. PHP continues to be not only an outstanding product, it also happens to be the one tool in my kit that has singlehandedly provided me with the opportunity to earn a very serious living. When asked how I use PHP, I have a simple answer. I use it to feed my family. For that, I thank each and every one of you, and you know who you are. Best, Mike Robinson Torstar Media Group Television -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: namespace separator ideas
They all look horrible. The idea of namespaces scrapped altogether is a good solution. :) Best, Mike Robinson David Zülke wrote: If we rule out :::, it should be - instead. Foo:bar:Baz::getTest()-foo(); vs Foo-bar-Baz::getTest()-foo(); The latter looks better to me. I'd still prefer Foo:::bar:::Baz::getTest()-foo(); though. - David Am 27.11.2005 um 01:28 schrieb Eric Coleman: I'd have to vote for either - or :. I perfer the later. \ is kinda crappy. Looks weird, as does %%. Looks like a mess. -- Eric Coleman On Nov 26, 2005, at 7:17 PM, Jasper Bryant-Greene wrote: Oliver Grätz wrote: Oliver Grätz schrieb: :::-:.. Whoops, forgot to add %% +1 for - here. It makes namespace hierarchies resemble diagrams of the same hierarchies (like inheritance in UML). It also visually makes sense, isn't hard to type, and doesn't look like a smiley (like : etc). -- Jasper Bryant-Greene General Manager Album Limited +64 21 708 334 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: 25/11/2005 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Timezone stuff - conclusion
I started the build when I got home at 3am ;-) It's now online: http://www.php.net/manual/en/timezones.php, I'll check later today where I want to link this in exactly. Nice work on this TZ stuff Derick. My thanks. Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Timezone stuff - conclusion
Christian Stocker wrote: IIRC the conclusion was, that Derick tries to make the TZ detection better (which was the only BC problem, AFAIK). And according to him, that's now almost solved (except some weird problems on Windows). He even made a pecl package for updating the TZ data easily should that change. If the TZ detection works reliable, I don't see any reason to revert or postpone Dericks work, the timezone handling of his implementation is so much better than the old one, it's really worth the upgrade for everyone having to deal with different timezones. Just my 2 cents. If I had 2 Phillipino Pesos and they meant anything I'd add them similarly. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] __toString()
Andi Gutmans writes: Believe me, from a usability perspective, I think __toString() working automagically is very nice... I'm just being less trigger happy and want to make sure we're covered. Humbly, this is a smart and prudent approach, to a nice piece of work I might add. Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ImageAntialias
Greg Trounson wrote: Actually I propose a new method for antialiasing: bool imageantialias ( resource im, bool on, int MODE ) where MODE is one of: AA_TRADITIONAL - Perform antialiasing the same way it's done now - that is to use a different antialiasing function for each primitive, most of which haven't yet been implemented. AA_SCALE - Draw the image to an internal buffer at 2x the requested size, using regular non-antialiased primitives, and downscale the result to the requested size with bilinear filtering. This produces nice antialiased images with very little duplication of code across primitives. Line thickness may need to be doubled to give the right effect. AA_TEXT - Draw/downsample the image as above, but omit text objects until after the image has been downsampled. This allows for clearer but non-antialiased text. Ugh. Painful short-term remedies... I understand the frustration, but given the excellent progress made lately on GD, both by Boutell-folk and the internal GD maintainer(s), IMHO I think it'd be better to wait until GD handles anti-aliasing properly. Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.0.5RC1 rolled
On my woody box, configure finished fine but with... Generating files updating cache ./config.cache creating ./config.status creating php5.spec creating main/build-defs.h creating scripts/phpize creating scripts/man1/phpize.1 sed: can't read ./scripts/man1/phpize.1.in: No such file or directory creating scripts/php-config creating scripts/man1/php-config.1 sed: can't read ./scripts/man1/php-config.1.in: No such file or directory creating sapi/cli/php.1 creating main/php_config.h creating main/internal_functions.c creating main/internal_functions_cli.c ... then during make: In file included from /usr/local/src/php-5.0.5RC1/ext/sqlite/libsqlite/src/sqliteInt.h:16, from parse.y:34: /usr/local/src/php-5.0.5RC1/ext/sqlite/libsqlite/src/config.h:1: /usr/local/src/php-5.0.5RC1/config.h: No such file or directory make: *** [ext/sqlite/libsqlite/src/parse.lo] Error 1 This by adding 'with-sqlite=shared' to the config line. Without this option it builds fine. Mike Wez Furlong wrote: I think I saw a configure related problem with the sqlite extension recently. I won't be able to check on this until thursday, maybe wednesday if things go well during the week. If someone else has time before I do, can they try building sqlite as a shared extension to verify if there was a problem? --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Beta 3
Thanks as usual to Edin for the quick turnaround on the Windows builds. +4,294,967,295 Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Timezone Function Name (Was: Re: [PHP-DEV] Re:[PHP-CVS]cvs: php-src/ NEWS /ext/datephp_date.cphp_date.h/ext/date/testsbug26198.phptbug29585.phptdefault-timezone-2.phpttimezone-configurat
Derick Rethans wrote: date_timezone_default_set -- Can you use this, which seems like the proper name, date_tz_default_set -- then alias this to it? Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] allow_url_fopen should be INI_ALL
Russell Nelson wrote: Graphical user interface designers understand the idea of an 'affordance'. An affordance is something whose operation is obvious simply by looking at it. An uparrow button moves something upwards. Uh, no. Affordances are the range of possible actions by a user, perceived affordances are the ranges of actions a user perceives is possible. You don't save people by filing down the sharp edges on a tool. You do it by telling them it's sharp. Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1
Olivier Hill wrote: Hi, I'm +1 on the goto patch aswell. What was the consent on the limit of a goto statement? Should it be able to jump outside a control block? Can it jump anywhere? And there are many more questions and issues just like this that expose the ugliness of what would _appear_ to be a handy feature. I don't pack any weight on this list so if someone with a -1 on this feature would like to kick it up to -2 I'd appreciate it. =) Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: References Problem Patch
Marcus Boerger wrote: And the patch addresses some very serious problems. Unfortunatley there are still a bunch of other issues unaddressed by now. To prevent 4.5 from popping up to soon i think we should all take some look into fixing those issues too. Anybody interested in those with a very deeply understanding of the engine should contact Derick, Dmitry or me (working since several weeks on those issues). IMHO, if the fix is available for the crashes and the only thing it breaks is some binary compatability, I'd say appling and releasing it would be the thing to do. And it's an awesome thing to do, dig in and fix some other stuff when the opportunity presents itself. I appreciate this _very_ much. There's still a ton of people, myself included, widely using PHP4. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.0.4 PEAR issue
Would 5.0.4pl1 be inappropriate? Two different versions of 5.0.4 seems odd, and 5.0.5 seems too drastic as you mentioned. Otherwise, IMHO, just make a brief announcement, point them to go-pear, and go through a normal 5.0.5 release cycle in a few weeks once a few more fixes make it in. Humbly, this isn't a big problem. Best, Mike Robinson Zeev Suraski wrote: Folks, We have a bit of a situation with the PEAR distro that's embedded in 5.0.4. It's missing the RunTest.php file, so PEAR doesn't install. The options we have, as far as I can tell, are: [a] Re-release 5.0.4 with that file [b] Release 5.0.5 with that file (seems a bit too aggressive considering there are no code changes, and may cause confusion) [c] Instruct people to install PEAR from http://go-pear.org I lean towards option [a]. Thoughts? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.0.4RC2 rolled
There seems to be something magical about the 0.4 release number. 3.0.4 worked really well. It wasn't until 0.4 that PHP4 compiled and ran without anything breaking for me. This is the first time PHP5 installed and ran all my stuff out of the box. Any ideas when 6.0.4 will be out? ;) Excellent work folks. Very nice. Best, Mike Robinson Zeev Suraski wrote: All, There have been several fixes since RC1. If there are no show stoppers found, we hope to release the final 5.0.4 early next week. Source: http://downloads.php.net/zeev/php-5.0.4RC2.tar.gz http://downloads.php.net/zeev/php-5.0.4RC2.tar.bz2 Windows binaries: http://downloads.php.net/edink/php-5.0.4RC2-Win32.zip http://downloads.php.net/edink/php-debug-pack-5.0.4RC2-Win32.zip http://downloads.php.net/edink/pecl-5.0.4RC2-Win32.zip Test away! Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] How to submit a new SAPI extension?
Is there going to be any licensing issues that need to be dealt with as far as you can see? Best, Mike Robinson George Wang writes: How can I submit a new PHP SAPI extension for our LiteSpeed Web Server? Send a patch to this list? Thanks, George Wang -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Anyone against requiring libxml2 2.6.x for PHP5.1?
I believe Debian and Fedora (Core 3) is up to 2.6.11 or better. IMHO requiring 2.6.x isn't too much of a stretch. mike -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: February 14, 2005 7:28 PM To: Adam Maccabee Trachtenberg; Christian Stocker Cc: PHPdev Subject: Re: [PHP-DEV] Anyone against requiring libxml2 2.6.x for PHP5.1? What's the status of 2.6.x in Linux distributions? Is it already standard in the latest SUSE/Redhat distros? Andi At 12:34 PM 2/13/2005 -0500, Adam Maccabee Trachtenberg wrote: On Sun, 13 Feb 2005, Christian Stocker wrote: Which is still less than 2.5.11, which is required for 5.0. Therefore Debian Stable people had to face this problem already with 5.0 ;) Fair enough. Asking people to upgrade to 2.6.x vs 2.5.11 is minor. -adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1
George Schlossnagle wrote: Yes, Andrei. This time you've gone to far. Your so-called 'humor' is all well and good until you start maligning c++. I think an apology is in order, both here (to Marcus, whose c++ophelia was surely offended as well, though he would never come out and say it in a public forum), in comp.lang.c++, and directly to Bjourne Stroustrup as well. Apology indeed. It's Bjarne Stroustrup. : ) Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] --with-ODBCRouter (database networking)
Dan Kalowsky wrote: As far as including the ODBCRouter in the PHP code, I wanted to know more about what it is before it goes further. Absolutely. The website is full of non-useful information regarding what ODBCRouter does. Well, you're too kind. I found the information contained therein misleading and extremely self-aggrandizing. For example, there is an explicit statement that the driver is recommended by Microsoft worldwide, and then links to page on Microsoft's site that simply states that the driver is required if you wish to pull data from MS Access 98 into Excel 98. Hardly a reason to include it in PHP's core. If it is another case of we want our proprietary driver included I'm voting against it. I believe that is the case. Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Why we don't like PHP /
Rasmus Lerdorf wrote: Hans Zaunere wrote: That presents somewhat of a chicken-and-egg problem. Production sites won't be compelled to make a move until PHP recommends it in some way, or if there is a killer feature that pulls people in, regardless of the perceived stability. Right, and they shouldn't. If there is no compelling reason to switch, why in the world should they? And why should we try to push them away from a stable platform? Absolutely. All things considered, the gap between PHP5 and Apache2 is understandable. Killer features don't draw people, solutions to killer problems do. When using Apache-2.x offers a solution to a killer problem that Apache-1.3.x can't solve, that gap will close on its own. I can't imagine why anyone would want to tamper with this process, it has worked so well for so long. Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] congrats and thanks
To all, Congratulations are in order. PHP5 is a monumental testament to open source. More importantly, it's also a glowing example of what software _can_ be when you have a dedicated group of committed individuals who take pride in their work, even when there isn't a paycheque or benefits package to compensate for it. My thanks to each and every one of you, the magnificent doc team, and especially the core guys that have shlogged on PHP all these years. PHP has and continues to supply me with the tools I use every day to feed my family. Humbly and sincerely, my thanks to you. Nice stuff. Best, Mike Robinson Torstar Media Group Television -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] E_STRICT
Ilia Alshanetsky wrote: On a related note, since a major PHP version is now being released, perhaps it is the time to finally remove old deprecated functionality that in many cases deprecated for years. I propose that we agree on a certain version as a minimum and remove all deprecated functionality that was marked as such prior to that version. I think this is a good idea, and this really should happen before PHP-5 goes gold. The negative impact and effects can be minimized by a prominent entry in the migration and/or NEWS documents. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] E_STRICT
Ilia Alshanetsky wrote: IMHO people will be expecting some functionality breaks if and when they upgrade to 5.0, not so when upgrading from 5.0 to 5.1. I believe that if we do not make the change now, we'd need to wait for the next major functionally altering release to make this change. Which puts this off indefinitely into the far future. Precisely. Might as well just do it and be done with it. Cheers Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PHP Benchmark
Christian Schneider wrote: Sebastian Bergmann wrote: http://www.sebastian-bergmann.de/PHP_Benchmark/ Any comments, feedback, corrections and additions are welcome, You've done a good job but we basically only see two things: a) PHP4 is an order of a magniture faster than PHP3. b) PHP5 is about the same speed as PHP4. No big surprises there, let's move on... I think maybe you're missing the point? The benchmark provides insight into changes in PHP speed between versions, major and minor. IMHO that's useful information, nice little sanity check on PHP performance. Just because a change is subtle doesn't mean it's not important. This would be a helpful PEAR addition. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Proposal: Array syntax
Kouber Saparev wrote: Perlish or not could not be a real reason for adding or not adding a feature in PHP. The important thing here is if it fits to the language concept or not. Indeed, and IMHO it does, much like ($a==$b)?... fits in quite well as an alternative to if ($a==$b)... It is an alternative syntax that makes things more readable and easier to use. Not an awful lot of magic, sexiness, or character savings involved. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re[2]: [PHP-DEV] Proposal: Array syntax
s0niX wrote: The problem i see when using array() (or list()) is that it nearly looks like it is a function, but it isn't. Using [] instead would clearly mark this difference. array() and list() are special language constructs, why shouldn't they look a bit special? This doesn't break backwards compatibility and it makes new code look better and more readable. Indeed. It's a nice idea. Having that syntax as an alternative to list() would be cool too. Whether it has enough steam to get around the magic rule I'll leave to others, because the rule is there for a reason. :) Best Regards Mike Robinson Am Mittwoch, 5. November 2003 um 09:49 schrieben Sie: AG Hi Christian, AG Personally I don't like having two ways of doing things. It makes it harder AG for people to read scripts. AG However, I think the proposed syntax is significantly more elegant than AG today's array() which makes me think twice about the idea and possibly AG making an exception to the rule. I think it'll improve the look of PHP AG scripts. Also I think people calling methods using call_user_method([$obj, AG method]); will find it sexier than the array() syntax. AG I guess I think it'd be interesting to see what other's think. Also, AG another point to check is if list() can also be converted into [] because AG having a hybrid wouldn't be too nice. AG Andi AG At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote: I propose to add an alternative (backward compatible) short array creation syntax: $a = [ 1, 2, 3 ]; and $a = [ 'a' = 42, 'b' = foo ]; It can also be used in function calls: img(['src' = logo.gif, 'alt' = Logo]); Reason behind this change: Arrays are used a lot and should therefore have as little syntactic overhead as possible. And I think the short syntax is also easier to read and write. A patch for the parser is trivial and is attached for Zend2. Note: I checked the newsgroup archive but couldn't find a discussion about this. After not hearing back about my proposed enhancement to debug_backtrace() and the dangling comma for function call parameters being rejected I wonder if I'm using the right mailing list for this :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Supporting php4 (was: Object Equality)
Andi Gutmans wrote: At 10:06 AM 11/3/2003 +0100, Thomas Lamy This is why I'm +1 for a 4.5 release, right before 5 goes out. This shouldinclude fixes that already are in 5, but were not applied to 4 for whatever reason. I'm sure the above fix is not the only one being held back.. The above fix is being held back because it could only be fixed in a decent way with the new object model in PHP 5. This is not something which you would find fixed in PHP 4.5. I think we should continue to support PHP 4 with bug fixes and minor additions but the focus should definitely be on PHP 5 right now. Absolutely. The process of a 4.5 release would be far too cumbersome on the PHP5 release plans. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Apache server on Linux not starting(undefined symbol: pthread_getspecific)
Regards Mike Robinson http://fiddy8.com/ Jani Taskinen wrote: Not-so-free-hint: Drop the --enable-experimental-zts option.. https://www.paypal.com/xclick/[EMAIL PROTECTED]no_note=1tax=0curren cy_code=EUR Yuck. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Apache server on Linux not starting(undefined symbol: pthread_getspecific)
Sorry. I meant: Jani Taskinen wrote: Not-so-free-hint: Drop the --enable-experimental-zts option.. https://www.paypal.com/xclick/[EMAIL PROTECTED]no_note=1tax=0curren cy_code=EUR Yuck. http://uptime.netcraft.com/up/graph?site=www.paypal.com Regards Mike Robinson http://fiddy8.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] before beta2 (is alive again) :-)
Marcus Börger wrote: The idea was then to allow NULL only if that's the default value. NULL is not a value. :P (Sorry, couldn't resist) Best Regards Mike Robinson http://fiddy8.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] variable_exists() patch
Robert Cummings wrote: Understandably PHP is slower than say C :) Generally I don't think there is need for everything to be a native function, however, that said, when the speed gain and utility are great in comparison to doing it as pure PHP then I think the option should be investigated. I think that's what's happening. The current isset() function fails many developers from what I can see Well, from what _I_ can see, a couple of developers are inconvenienced, nothing more. It was pointed out earlier that setting a variable to NULL has very little value, and after 6 years and a couple million lines of PHP I still haven't done it. I don't see the need for implementing this in userland, let alone in the core. The proposed function for all intents and purposes will _appear_ to be exactly the same is isset, but provide different behaviour. IMHO, that's a _huge_ inconsistency that ends the investigation. Of course, if this functionality is so critical to your applications there's no reason why you can't implement and maintain it in your own PHP install, and even make the patch available to others. :) [Insert random string extolling virtues of Open Source here] Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Feature proposal
No offense, but I see this feature as a bad thing in so many ways and on so many levels my skin is crawling. :) Regards Mike Robinson http://fiddy8.com/ I have to fight with people that using error suppression operator - they just hide their bugs. I wrote simple patch that allows set disable_error_suppression=On in php.ini that causes engine to ignore '@' operators. http://strony.wp.pl/wp/wmeler/error_suppression.patch.txt Regards, Wojtek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sqlite documentation
Andi Gutmans wrote: At 04:32 PM 6/24/2003 -0400, Sterling Hughes wrote: On Tue, 2003-06-24 at 17:41, Andi Gutmans wrote: Do we have documentation for the sqlite extension? yep... Not sure if its on php.net, but its written and committed. Used to be available at http://docs.php.net/, but that's having problems at the moment. Thanks to both you and Derick :) Yes, absolutely outstanding, as usual. IMHO this is an _awesome_ addition to php. Well done. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Moving to PECL
It's not like PHP5 will get out the door any time soon. If the plan is to move all php5 extensions to PECL, why wait? Move them. Fix things. Seems like a good idea, and fairly straight forward, especially when you have someone as capable as Sterling volunteering to do the work. Best Regards Mike Robinson (Sorry if I missed something, but this seems like a no-brainer) Edin Kadribasic wrote: On Sun, 8 Jun 2003, Rasmus Lerdorf wrote: Basically my point is that instead of pushing extensions into the current void that is PECL, we need to pull PECL from the void and make it work first. You seem to want to take the reverse approach. Push everything into PECL and by doing that force someone to fix it, versus fixing PECL and then having people fall over themselves trying to get their extensions into this new brilliant framework. This was exactly what I was trying to say. Breaking stuff in hope that it will force people to fix things afterward instead of making the framework work first seemed as the wrong approach to take. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP-4.3.2 Apache2
I'm curious as to what the status is of the fixed apache2handler stuff that was discussed regarding whether or not to include it in the 4.3 tree. I was under the impression that despite some reluctance to include it (because it was new), it was decided to include it because it was actually a fix. Did it in fact make it in, and included in the 4.3.2RC1 release? TIA. Best Regards Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
