[RFC] Bare Name Array View as Markdown

Hi!

That’s a whole five characters, seven including spaces, for your most
common case (identifier-like key). In JavaScript, you can avoid
quoting the key for this common case. I propose something similar for
PHP. Where the key fits the profile of IS_STRING, this RFC proposes
that you can do this instead:

stringKey: 3,

You can already do stringKey => 3 :) And saving characters is not really
a big priority. Changing language syntax and making millions of people
to learn new syntax just to save a couple of chars does not look like a
big win to me.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Good evening,

I have created an RFC containing two proposals.

This should be two RFCs then. Two proposals should be two RFCs.

Good evening,

I have created an RFC containing two proposals.

The first is a less cumbersome syntax for arrays. At present, string
keys in arrays are declared like this:

“stringKey” => 3,

That’s a whole five characters, seven including spaces, for your most
common case (identifier-like key). In JavaScript, you can avoid
quoting the key for this common case. I propose something similar for
PHP. Where the key fits the profile of IS_STRING, this RFC proposes
that you can do this instead:

stringKey: 3,

We already voted no for this when discussing the short array syntax. See
the vote under "Array short syntax" at
https://wiki.php.net/todo/php54/vote

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Good evening,

I have created an RFC containing two proposals.

The first is a less cumbersome syntax for arrays. At present, string
keys in arrays are declared like this:

“stringKey” => 3,

That’s a whole five characters, seven including spaces, for your most
common case (identifier-like key). In JavaScript, you can avoid
quoting the key for this common case. I propose something similar for
PHP. Where the key fits the profile of IS_STRING, this RFC proposes
that you can do this instead:

stringKey: 3,

Now it’s only two characters, three including spaces, for the most
common case. It makes declaring arrays more convenient.

I don't believe in "less characters is better". I consider having two
syntaxes which work notably different confusing.

const FOO = 23;
$a = [
FOO => 42,
FOO: 3.14152
];

will lead to quite confusing results. We shouldn't go there imo.

The second proposal is a less cumbersome syntax for dereferencing
arrays with string keys. At present, you need to do this:

$myArray[“foobar”][“andSoOn”][“moreKeys”][“etc”]

That’s four characters per dereference. Yet for objects, only two are
needed:

$myObject->foobar->andSoOn->moreProps->etc

Thus, this RFC also proposes the following syntax for dereferencing
arrays with string keys, where said keys fit the profile of IS_STRING:

$myArray:>foobar:>andSoOn:>moreProps:>etc

The :> syntax can be considered provisional, I’m open to better
alternatives.

Same as above - the benefit is minimal and might be easily misleading.

johannes

Where the key fits the profile of IS_STRING, this RFC proposes that you can do this instead:

stringKey: 3,

Now it’s only two characters, three including spaces, for the most common case. It makes declaring arrays more convenient.

I should note that an added bonus of passing this RFC would be that it would clear up what syntax to use for named parameters. Currently, syntax is up for debate.[0] I’m unhappy with test(foo => “bar”) because that’s inconsistent with arrays which do not quote bare word names with =>, and I think test($foo => “bar”) would be confusing. By adding the bare word colon syntax, there’d be a clear syntax that’s the same for both named parameters and arrays, if or when named parameters are implemented:

foobar(4, 7, foo: 3, bar: true, “parameter with spaces” => “baz”);
// Would be the same as
$myParams = [4, 7, foo: 3, bar: true, “parameter with spaces” => “baz”);
call_user_func_array(‘foobar’, $myParams);

[0]https://wiki.php.net/rfc/named_params#syntax

Andrea Faulds
http://ajf.me/

I don't like it because I think it reduces the readability of array
definitions too much.

My preference is syntax that makes it easy for me to convey the meaning of
my code to YOU, at a glance. In general, this means consistency. Typing a
couple of extra characters for the sake of readability is perfectly
reasonable to me.

As far as the, "we did that, so we should do this" argument I've been seeing
a lot: Your feature should stand on its own within the ENTIRE context of the
language. Many mistakes have been made in the lifetime of PHP. Don't point
at any one feature and say that it's a good reason to include this feature.

Bryan

I propose something similar for PHP. Where the key fits the profile of IS_STRING, this RFC proposes that you can do this instead:

stringKey: 3,

Now it’s only two characters, three including spaces, for the most common case. It makes declaring arrays more convenient.

Something I’m considering adding to the RFC is support for quoted names, such that you could do this:

[“stringKey”: 3]

Now, obviously, you can already do the same with the double arrow:

[“stringKey” => 3]

If that’s the case, then what’s the advantage? Well, it is even closer to JSON and JavaScript now than before. By adding this, we’d have the bareName: and “quoted name”: syntaxes established in arrays, and PHP developers would become familiar with them. (Incidentally, Apple’s new Swift language announced a few hours ago uses [“key”: 3] for their hash map literals, though that’s a bit off-topic.)

With that groundwork laid, a new RFC could be created proposing object literals with identical syntax to JSON’s objects, meaning you could paste JSON into PHP and (unless it had dollar signs) it would be perfectly valid PHP code and parse as you expect. It would support the “quoted key”: and unquotedKey: formats, but none other, thus aligning itself with JavaScript (and hence JSON, which uses “quoted key”: exclusively). That would also be useful for creating disposable objects. At present, the closest thing we have is immediately casting arrays to objects, which is tedious, as well as acting weirdly in some situations (integer keys in particular).

The JSON stuff is not, however, part of this RFC. It’s a separate RFC and thing I would implement if a quoted name syntax was added to this RFC and it passed. Also, I haven’t yet added “quoted key”: syntax, but I’m considering it.

--
Andrea Faulds
http://ajf.me/

Andrea, did you consider implementing something more like Ruby's
symbols, rather than a variation on the existing array literal syntax?
I feel like that might solve any potential ambiguities in terms of
constant resolution (as mentioned in another subthread), wouldn't
require a separate [foo: bar] variant on the existing syntax, and may
be useful in other contexts too (such as array dereferencing).

The problem with Ruby-style symbols is twofold. First, we don’t have a free character in PHP to use to denote a symbol, so it would have to be two characters. In that case, there’d be no advantage in using it over a string. Secondly, Ruby-style symbols are completely separate from strings, with symbol keys and string keys being different. Nothing in PHP deals with symbols, however, everything deals with strings. So for it to be useful we’d either have to start using it everywhere, which won’t happen, or have it just be another syntax for strings, which would be useless as it’s no shorter.

As for the array dereferencing syntax: it should probably be an RFC
and patch on its own. To be honest, my initial reaction is negative —
I think the proposed syntax blurs the lines between arrays and objects
(I know it's a different digraph, but it's going to look really
similar when scanning code), and I'm not yet sold on it being
particularly useful.

I’m not entirely sold on :> either, but it’s the best idea I’ve had so far. I made a single RFC as I think the two features are complementary. As both use T_STRING, anything you can define with : you can dereference with :>, and the colon in :> is obviously inspired by the colon syntax. I may consider splitting the proposals into their own RFCs yet, though. I want to hold separate votes, anyway.

--
Andrea Faulds
http://ajf.me/

The first is a less cumbersome syntax for arrays. At present, string
keys
in arrays are declared like this:

“stringKey” => 3,

[...] Where the key fits the profile of IS_STRING, this RFC proposes
that
you can do this instead:

stringKey: 3,

Interestingly, I notice Ruby's hash syntax has two variants very
similar to
this [http://www.ruby-doc.org/core-2.1.2/Hash.html].

However, in that case, the unquoted version represents a use of Ruby's
special "Symbol" type, which is actually a different fundamental type
from a
String. So the following actually defines a 2-element hash, with one
Symbol
key and one String key:

foo = { myKey: 'bar', 'myKey' => 'bob' }
=> {:myKey=>"bar", "myKey"=>"bob"}

You've mostly pre-empted the question I wanted to ask. :)

Andrea, did you consider implementing something more like Ruby's
symbols, rather than a variation on the existing array literal syntax?
I feel like that might solve any potential ambiguities in terms of
constant resolution (as mentioned in another subthread), wouldn't
require a separate [foo: bar] variant on the existing syntax, and may
be useful in other contexts too (such as array dereferencing).

As for the array dereferencing syntax: it should probably be an RFC
and patch on its own. To be honest, my initial reaction is negative —
I think the proposed syntax blurs the lines between arrays and objects
(I know it's a different digraph, but it's going to look really
similar when scanning code), and I'm not yet sold on it being
particularly useful.

Hi,

Actually Ruby's symbol is like PHP's string. It's immutable and it's
interned. Unlike Ruby's strings which are mutable. So the question is in
the syntax only...