Re: [PHP-DEV] ArrayPath
On Tue, Oct 7, 2014 at 9:05 AM, Mathias Grimm
wrote:
> Hi,
> I would like to suggest something for php like a class I am using
>
> https://github.com/mathiasgrimm/arraypath
>
> The reason is to access arrays like this:
>
> $idx3 = ArrayPath::get('idx1/idx2/idx3', $_POST, 'myDefaultValue');
>
>
> Regards,
> Mathias
>
Hi Mathias,
The new null coalesce operator in PHP 7 achieves what you're looking for
here. See https://wiki.php.net/rfc/isset_ternary
Best regards,
--Matthew
Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator
Hi Andrea, This is great -- thanks to you and Nikita for the work here. Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b, 'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable, and it avoids any possible confusion about precedence within the expressions. Either way, still +1 for this feature. Best regards, --Matthew
Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single switch statement
On Wed, Aug 13, 2014 at 3:24 AM, Peter Cowburn wrote: > > My thoughts on the topic? I think we're in danger of letting "process" get > in our way here. It's a bug fix which IMHO should even be thrown into 5.6 > (this is a bug fix!). Going through the RFC process, being forced to wait > for 5.7 or 7, extended discussions on the list... it all just seems > unnecessary. But, that's just the opinion of a docs guy. :-) +1, my thoughts as well. Best regards, --Matt
Re: [PHP-DEV] camelCase on Exception methods?
On Thu, Dec 6, 2012 at 4:34 PM, Kris Craig wrote: > Hey guys, > > Please forgive me if this has already been addressed, but could somebody > tell me why all the methods for the Exception class are in camelCase? I > don't want to wade too deeply into the "consistency vs. BC" rabbit hole > here, but I'm just wondering what the general consensus is on this right > now. > > http://php.net/manual/en/class.exception.php > > > Thanks! > > --Kris > Hi Kris, See http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS#137 Best regards, --Matthew
Re: [PHP-DEV] Change bug tracker "bogus" to "not-bug"?
On Tue, Jan 24, 2012 at 3:16 PM, Paul Dragoonis wrote: > On Tue, Jan 24, 2012 at 11:12 PM, Christopher Jones > wrote: >> >> >> On 01/24/2012 03:11 PM, Justin Martin wrote: >>> >>> Hello, >>> >>> With some frequency, I find bugs which are not "bogus", so much as they >>> are reported based on a misunderstanding. Usually this happens for >>> documentation problems, where someone has misunderstood what the >>> documentation says, or hasn't read the documentation >>> thoroughly enough. >>> >>> I'd like to propose simply changing the term "bogus" to "not-bug". This >>> would more politely and clearly indicate the nature of the way the bug is >>> being closed, in addition to the comment that one ordinarily leaves. >>> >>> Those I've spoken to in php.doc agree. Any objections? >>> >>> Thank you, >>> Justin Martin >>> >> >> I'm +1 on this. It's time for a new, more collaborative approach. > > Sure, I'll +1 on this. The "bogus" implies "RTFM, bitch", which isn't > professional at all :-) I've felt this way for a long time. Big +1 on changing this. Cheers, --Matthew -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support negative indexes for arrays and strings
On Fri, Jan 14, 2011 at 10:21 AM, Marc Easen wrote: > Hello everyone, > > I would like to open the discussion around the support of negative indexes, > as I feel a lot of developers will benefit from this syntactical sugar. It would be convenient, but PHP already allows arrays to have negative indices. Changing their behavior would be a major BC break. Best Regards, --Matthew -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting Binary Notation for Integers
On Wed, Nov 10, 2010 at 2:51 PM, Gustavo Lopes wrote: > On Wed, 10 Nov 2010 21:31:19 -, Jonah H. Harris > wrote: > >> Hey all, >> >> I was recently working on some code which made use of bit arrays and I >> came across feature request 50648: Format for binary numbers. While it's >> just >> more syntactic sugar (0b1011010 vs 2010/0x7da/03732), it doesn't seem >> like too bad of an idea and it is also supported by a few other languages. >> If there's any interest, I'll clean up the patch and resubmit. >> > > I think it's a good idea. > > It won't spark interest in those that have already memorized the more > compact hexadecimal representation of nibbles, but otherwise it's useful a > simple non-BC breaking addition. Agreed. I have often thought this would be useful. Best regards, --Matthew -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] Type hinting
On Thu, Jul 29, 2010 at 8:18 AM, Kalle Sommer Nielsen wrote: > > Hello Zeev > > 2010/7/29 Zeev Suraski : > > With the revived interest in the neighbourhood of type hints in the last few > > days I'm resending this email from a few weeks ago. > > > > In a nutshell, use auto-conversion for scalar type hints, and modify the > > conversion rules throughout PHP to handle 'senseless' conversions that > > result in data loss differently - by emitting E_TYPE. > > > > Zeev > > Ill be very much against adding a new error level for typing, E_NOTICE > or E_WARNING should be *enough* for letting the user know of any data > loss. I don't think it would be a good idea for adding a new error > level for specific language features, if we went to use exceptions for > everything it would however have been a sleek solution but we don't. > > As for which solution we should take, we need a userland vote and a > core vote foreach of the 3 solutions we have atm.: > * Strict typehinting (as whats currently in trunk) > * Weak typehinting (with silent autoconvertion) > * Weak typehinting (that emits warnings/notices/type warnings) > > It would be nice to have such a vote so the coming RM's also have > control over which solution is preferered and eventually why its > preferered. While on the subject of type-hinting, I propose the idea of a "callback" type hint, which accepts anything that is callable. This is useful because it allows a function to be sure a given argument is callable, and can then safely use it to call a function which requires a callback, or safely call it using $f(). I think this also falls in the category of array/Object type hints meaning that it doesn't present the controversies of strict vs. weak, so I think it could be a good candidate for inclusion. I made a patch a few weeks back to do this and can post it if anyone is interested. Best regards, --Matthew -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [patch] Allow array_change_key_case to support ucfirst and lcfirst
Hi All,
I came across a situation where I had to make the first character of an
arrays keys uppercase, and found the array_change_key_case function, but
noticed it only supported CASE_UPPER and CASE_LOWER. Attached is a patch to
also add support for CASE_LCFIRST and CASE_UCFIRST.
The patch is against PHP_5_3. I wasn't sure which branch I should write it
for--let me know if it should be against another branch. This is my first
patch submission so any comments are appreciated.
Regards,
--Matthew
Index: ext/standard/array.c
===
--- ext/standard/array.c(revision 288546)
+++ ext/standard/array.c(working copy)
@@ -63,6 +63,8 @@
#define CASE_LOWER 0
#define CASE_UPPER 1
+#define CASE_LCFIRST 2
+#define CASE_UCFIRST 3
#define COUNT_NORMAL 0
#define COUNT_RECURSIVE1
@@ -121,6 +123,8 @@
REGISTER_LONG_CONSTANT("CASE_LOWER", CASE_LOWER, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("CASE_UPPER", CASE_UPPER, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("CASE_LCFIRST", CASE_LCFIRST, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("CASE_UCFIRST", CASE_UCFIRST, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("COUNT_NORMAL", COUNT_NORMAL, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("COUNT_RECURSIVE", COUNT_RECURSIVE, CONST_CS |
CONST_PERSISTENT);
@@ -2711,10 +2715,20 @@
break;
case HASH_KEY_IS_STRING:
new_key = estrndup(string_key, str_key_len - 1);
- if (change_to_upper) {
- php_strtoupper(new_key, str_key_len -
1);
- } else {
- php_strtolower(new_key, str_key_len -
1);
+ switch (change_to_upper) {
+ case CASE_UPPER:
+ php_strtoupper(new_key,
str_key_len - 1);
+ break;
+ case CASE_LCFIRST:
+ php_lcfirst(new_key);
+ break;
+ case CASE_UCFIRST:
+ php_ucfirst(new_key);
+ break;
+ case CASE_LOWER:
+ default:
+ php_strtolower(new_key,
str_key_len - 1);
+ break;
}
zend_hash_update(Z_ARRVAL_P(return_value),
new_key, str_key_len, entry, sizeof(entry), NULL);
efree(new_key);
Index: ext/standard/string.c
===
--- ext/standard/string.c (revision 288546)
+++ ext/standard/string.c (working copy)
@@ -2513,11 +2513,12 @@
/* {{{ php_ucfirst
Uppercase the first character of the word in a native string */
-static void php_ucfirst(char *str)
+PHPAPI char *php_ucfirst(char *s)
{
- register char *r;
- r = str;
- *r = toupper((unsigned char) *r);
+ unsigned char *c;
+ c = (unsigned char *)s;
+ *c = toupper(*c);
+ return s;
}
/* }}} */
@@ -2536,22 +2537,24 @@
RETURN_EMPTY_STRING();
}
- ZVAL_STRINGL(return_value, str, str_len, 1);
- php_ucfirst(Z_STRVAL_P(return_value));
+ str = estrndup(str, str_len);
+ php_ucfirst(str);
+ RETURN_STRINGL(str, str_len, 0);
}
/* }}} */
/* {{{
Lowercase the first character of the word in a native string */
-static void php_lcfirst(char *str)
+PHPAPI char *php_lcfirst(char *s)
{
- register char *r;
- r = str;
- *r = tolower((unsigned char) *r);
+ unsigned char *c;
+ c = (unsigned char *)s;
+ *c = tolower(*c);
+ return s;
}
/* }}} */
-/* {{{ proto string ucfirst(string str)
+/* {{{ proto string lcfirst(string str)
Make a string's first character lowercase */
PHP_FUNCTION(lcfirst)
{
@@ -2566,8 +2569,9 @@
RETURN_EMPTY_STRING();
}
- ZVAL_STRINGL(return_value, str, str_len, 1);
- php_lcfirst(Z_STRVAL_P(return_value));
+ str = estrndup(str, str_len);
+ php_lcfirst(str);
+ RETURN_STRINGL(str, str_len, 0);
}
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Monday, July 6, 2009, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals list > regarding type hinting based on my original patch. Since then the patch has > been revised to address the major concerns that were identified (breakage of > binary compatibility) as well extended with additional functionality (object > hint, type casting, reflection support, etc...). +1 Regards, Matthew > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine btw). > To keep the process simple & flamewar free, please restrict yourself to +/- > (1/0), next week monday I'll run a tally of the votes and based on the result > we can determine how to proceed further. > > Ilia > > -- > 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-DEV] fix for array_map arg info
Hi, The arg info for array_map appears to be incorrect. It lists 3 arguments as required, when in fact there are only 2 required. Attached is a small patch to fix it. Regards, Matthew Index: basic_functions.c === RCS file: /repository/php-src/ext/standard/basic_functions.c,v retrieving revision 1.725.2.31.2.64.2.91 diff -u -r1.725.2.31.2.64.2.91 basic_functions.c --- basic_functions.c 15 Jun 2009 08:32:38 - 1.725.2.31.2.64.2.91 +++ basic_functions.c 18 Jun 2009 19:14:02 - @@ -589,10 +589,9 @@ ZEND_ARG_INFO(0, callback) ZEND_END_ARG_INFO() -ZEND_BEGIN_ARG_INFO_EX(arginfo_array_map, 0, 0, 3) +ZEND_BEGIN_ARG_INFO_EX(arginfo_array_map, 0, 0, 2) ZEND_ARG_INFO(0, callback) - ZEND_ARG_INFO(0, arg1) /* ARRAY_INFO(0, arg1, 0) */ - ZEND_ARG_INFO(0, arg2) /* ARRAY_INFO(0, arg2, 0) */ + ZEND_ARG_INFO(0, arr) /* ARRAY_INFO(0, arr, 0) */ ZEND_ARG_INFO(0, ...) ZEND_END_ARG_INFO() -- 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
Option [a] seems like the most logical thing to do, would probably work the best. It might be nice to note on php.net somewhere right now before this is fixed that PEAR will not 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
[PHP-DEV] CVS Account Request: matt
I would like to help with documentation and contribute anything else possible, and also I was told to request a CVS account by [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
