Re: [PHP-DEV] BC break in 5.3.2 - 5.3.3 with parent:: and __call/__callStatic
Until version 5.3.2 this worked fine, starting from version 5.3.3 parent::getFoo() calls __callStatic() instead of __call(). This is a really bad BC change which i thought you decided to accept only in minor versions change and not patch-level versions change. Anyway, I would even be willing to do some changes to my codebase, but what is the solution? I can't see any other way to do this with the obvious assumptions that my design is good and that I don't know anything about the parent class except there is a getFoo() method implemented somehow. My wish is that you restore the 5.3.2 behaviour, which sounds very reasonable, and maybe introduce another way when you actually want to get rid of the context, something like static:: The change has been reverted in SVN. Great. Is there any chance to see 5.3.4 anytime soon? -j -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.15 and 5.3.4
It has been a while since the last releases in the stable branches of PHP and it is time to get the process going once again. This e-mail is a 2 week notice prior to the RC1 for both versions, the goal is to have the final releases completed by mid-December. As far as PHP 5.2 is concerned 5.2.15 is the last release before EOL that was announced this summer, the goal of this release is to finalize the various key and security fixes that were made since the last release. When it comes to 5.3.4, this is just a regularly scheduled bug-fix release. Ilia Alshanetsky Johannes Schlüter 5.2 5.3 Release Masters -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] lenient datetime
Hi!
As I previously noted, in DateTime module there's no way to make
DateTime format parser to parse the string if the string contains more
data that the format supplies - i.e. if you need 'Y-m-d' and you have
string '2010-11-02 12:30' - you can't make DateTime accept it without
pre-parsing. The attached patch adds format character '+' that
implements that - i.e., if you use format 'Y-m-d+' then the string
'2010-11-02 12:30' will be parsed successfully, as well as '2010-11-02'
and string with anything following the date.
The character would make the format 'lenient' when used in any position
in the string, doesn't have to be at the end.
Any objections? If not, I'll add some unit tests and commit it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Index: lib/parse_date.c
===
--- lib/parse_date.c(revision 305040)
+++ lib/parse_date.c(working copy)
@@ -24824,6 +24824,7 @@
timelib_sll tmp;
Scanner in;
Scanner *s = in;
+ int allow_extra = 0;
memset(in, 0, sizeof(in));
in.errors = malloc(sizeof(struct timelib_error_container));
@@ -25046,7 +25047,9 @@
case '*': /* random chars until a separator or number
([ \t.,:;/-0123456789]) */
timelib_eat_until_separator((char **) ptr);
break;
-
+ case '+':
+ allow_extra = 1;
+ break;
default:
if (*fptr != *ptr) {
add_pbf_error(s, The format separator
does not match, string, begin);
@@ -25055,9 +25058,10 @@
}
fptr++;
}
- if (*ptr) {
+ if (*ptr !allow_extra) {
add_pbf_error(s, Trailing data, string, ptr);
}
+ while(*fptr == '+') fptr++; /* ignore trailing +'s */
if (*fptr) {
add_pbf_error(s, Data missing, string, ptr);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] lenient datetime
Like the idea, Couple of questions... What would happen if the string contained a matching pattern twice or me, which would be 'returned', also does this allow the rest of the string to be pretty much junk. (haven't had time to test patch as miles from a computer) -- James Butler Sent from my iPhone On 3 Nov 2010, at 17:16, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! As I previously noted, in DateTime module there's no way to make DateTime format parser to parse the string if the string contains more data that the format supplies - i.e. if you need 'Y-m-d' and you have string '2010-11-02 12:30' - you can't make DateTime accept it without pre-parsing. The attached patch adds format character '+' that implements that - i.e., if you use format 'Y-m-d+' then the string '2010-11-02 12:30' will be parsed successfully, as well as '2010-11-02' and string with anything following the date. The character would make the format 'lenient' when used in any position in the string, doesn't have to be at the end. Any objections? If not, I'll add some unit tests and commit it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php lenient_date.diff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [alexander.schrij...@gmail.com: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON]
Yes, there is a reason: As it was explained before, lemon would not display token names but actual token values. So instead of Unexpected T_PAABLAH it would say Unexpected '::' ... hello, value of some tokens is not what would be expected either. Think a bit about T_STRING for example. There should be a smart algorithm implemented. BTW bison-createdparsercan use a callback (yytnamerr) to replace tokens with something human-readable. Why not use it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allowing an array as a parameter for snmpget()/snmpgetnext() [repost]
I think you will need to push for their inclusion (involving requesting svn access and doing it yourself) precisely because there is no one is currently looking after the extension. Chris On 10/23/2010 12:46 AM, Jorrit Kronjee wrote: Chris and others, Since SNMP didn't have any unit tests to begin with, I just looked at some examples. I guess I looked at the wrong ones (in the current version 5811 unit tests have the SKIPIF sections, compared to 5416 that do not). Before I start adding these, can someone tell me what to do to get this patch included? The maintainers of the SNMP extension have been silent so far. I would love to make this patch fly, but if it's just not going to happen then that's fine with me too. Regards, Jorrit Kronjee On 10/11/2010 04:37 PM, Christopher Jones wrote: Hi Jorrit, I'm not able to comment on the question of inclusion, but I did notice that the .phpt files are missing SKIPIF sections. See http://qa.php.net/write-test.php Chris On 10/11/2010 05:43 AM, Jorrit Kronjee wrote: Dear list, A few weeks ago I submitted the attached patch to this list. Apart from some initial comments I've not heard if the patch is good enough now to be added to the PHP sources. Is there anything still missing? Regards, Jorrit Kronjee -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] lenient datetime
Hi! What would happen if the string contained a matching pattern twice or me, which would be 'returned', also does this allow the rest of the string to be pretty much junk. Yes, the rest of the string (i.e. everything after the format was matched, while ignoring +) can be anything. I.e., as soon as the requirements of the format (like Y-m-d) is satisfied, it doesn't matter what else the string has. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO_DBLIB Native PHP Type binding
Before I gut PDO_DBLIB one more time to implement native parameter binding for stored procedures, what are the thoughts on returning the column values from the database as the native PHP type when possible? Currently everything is returned as a string, incurring overhead for conversion and creating problems hinting at the desired binding type for BLOBS and numeric data types. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] PDO_DBLIB Native PHP Type binding
On Nov 3, 2010, at 9:52 PM, Stanley Sufficool wrote: Before I gut PDO_DBLIB one more time to implement native parameter binding for stored procedures, what are the thoughts on returning the column values from the database as the native PHP type when possible? Currently everything is returned as a string, incurring overhead for conversion The design philosophy was to pull the data out as strings as this gives the highest data fidelity (especially with the various numeric types) and is a pragmatic choice for the majority of web apps which are largely in text land anyway, and typically are not bottlenecked on the performance of converting database column values. Some drivers, particularly postgres, are unable to request string data and therefore return their results in the type that most closely matches the C datatype forced on it by the API. This has been a source of complaints from some about the consistency of the returned data for apps that are designed to run against multiple database backends. I would advise against changing the behavior of the driver if possible, and against changing it away from the established stringiness of PDO without good reason. and creating problems hinting at the desired binding type for BLOBS and numeric data types. Can you elaborate on this? You can explicitly set the desired binding via bindColumn. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] PDO_DBLIB Native PHP Type binding
On Wed, Nov 3, 2010 at 8:25 PM, Wez Furlong king...@gmail.com wrote: On Nov 3, 2010, at 9:52 PM, Stanley Sufficool wrote: Before I gut PDO_DBLIB one more time to implement native parameter binding for stored procedures, what are the thoughts on returning the column values from the database as the native PHP type when possible? Currently everything is returned as a string, incurring overhead for conversion The design philosophy was to pull the data out as strings as this gives the highest data fidelity (especially with the various numeric types) and is a pragmatic choice for the majority of web apps which are largely in text land anyway, and typically are not bottlenecked on the performance of converting database column values. Some drivers, particularly postgres, are unable to request string data and therefore return their results in the type that most closely matches the C datatype forced on it by the API. This has been a source of complaints from some about the consistency of the returned data for apps that are designed to run against multiple database backends. I would advise against changing the behavior of the driver if possible, and against changing it away from the established stringiness of PDO without good reason. One reason was to bring the driver in line with the behavior of the PDO sqlserv driver ( http://msdn.microsoft.com/en-us/library/cc296193.aspx ) Eventually I would like yo make the 2 interchangeable and have PHP/PDO applications run the same on Win32 and Linux. and creating problems hinting at the desired binding type for BLOBS and numeric data types. Yes, you are right. I can bind columns as strings and parameters as a specific data type independently. Can you elaborate on this? You can explicitly set the desired binding via bindColumn. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
