Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi Rowan,
On Fri, 2015-03-20, at 13:17, Rowan Collins wrote:
I personally like the idea of string offsets having similar but slightly
different syntax from array offsets, to make clear which you're using. I
use {} instead of [] for that reason, but at the moment the syntaxes are
completely interchangeable as far as I can tell.
I'm in exactly the same situation; I'd thought for ages that the curly-brace
syntax was only valid for string offsets, so I use them in favour of square
brackets to avoid confusion.
I'd support reserving curly-braces for string offsets only (and vice-versa
for square brackets / arrays).
One awkward edge-case is where a class implements both __toString() and
ArrayAccess. It would be nice if you could distinguish which type of offset
you're accessing without casting.
Theoretical phpt test: http://pastebin.com/9b6YLC29
Vik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi Alex,
On Fri, 2015-03-20, at 13:38, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Certainly it breaks BC (and would presumably have to wait until PHP 8), but
if we were starting from scratch today, why would it make sense to have two
syntaxes that do exactly the same thing?
Vik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Alex, On Fri, 2015-03-20, at 17:19, Alex Bowers wrote: When you say restrict to one each. Do you mean one for strings and one for arrays? Yes, that's what I mean. I would propose square brackets for array offsets, and curly braces for strings. If so I'd have to disagree with this, since having the same operation available to both is less likely to give mistakes. Can you give an example of an actual benefit for this? Since this would cause a backwards incompatible change. I can't imagine many places if any use the curly brackets for arrays or strings, but since it exists there may be people using it. Changing the behaviour of this to only work for one of the two options seems unnecessary in the name of making code slightly more apparent on initial reading. But variable names and so on should be used to help distinguish from array or strings anyway. Yes, I'm very conscious of the substantial BC break, which is why I would target PHP 8 (or even 9, following a deprecation cycle). I guess you and I disagree on the benefits of syntax that is more self-documenting. The vast majority of PHP developers don't use variable names to indicate data types; the only common convention I've seen is for arrays' names to be pluralized (ie. $items, $rows etc.), but this doesn't really help. Often when less- experienced developers come across code that uses subscript syntax on a variable, they typically assume that the variable is an array (since string offsets are so much less common), and in doing so, introduce bugs. If the use of curly-braces was mandatory for string offsets, then code like this couldn't be mistaken for anything else. Vik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC - Array slice syntactic sugar
Hi Alex,
On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Maybe you misunderstand me, I am against using two syntaxes for different
things.
Based on your reply; yes, I'm definitely misunderstanding! In summary, we
already have two different operations:
(1) Accessing an array's element using subscript notation, eg:
$foo = array('bar'); var_dump($foo[0]); // string(3) bar
(2) Accessing a string's character using subscript notation, eg:
$foo = 'bar'; var_dump($foo[0]); // string(1) b
And we already have two different syntaxes: $var[$offset] and $var{$offset}.
So we have two syntaxes that each perform two operations. Are we in
agreement that this isn't a good thing?
Sorry that this is all a little off-topic, but I'm interested in people's
opinions because I'm considering a future RFC. My proposition would be to
restrict the two subscript syntaxes to one operation each. And if your slice
sugar RFC aims to augment the functionality of either one or both of these
syntaxes, then that's relevant to me.
Vik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
I've always liked how callbacks (well, function pointers) are handled in C -
using the function name without parentheses. eg.
$a = $object-method;
But this wouldn't work in PHP as is, since property and method names would
collide. How do people feel about the fact that we have separate property and
method namespaces? Does it add value?
Vik
On Thursday, 19 March 2015, 12:48, Sebastian B.-Hagensen
sbj.ml.r...@gmail.com wrote:
Hi,
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
$object-method($methodArg1, $methodArg2); };
--
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
