Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65906
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.212.48 cause and error)
MIME-Version: 1.0
Date: Mon, 18 Feb 2013 10:43:08 -0500
Message-ID: <CADqTB_iphkDnW4bZZTw2Ty+TmTJXOMKDFKXjqa4gBWDwxpiONQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae9cfcb9ae4a81104d60194c2
Subject: short syntax for construction/initialization, named arguments and
 (future) annotations
From: rasmus@mindplay.dk (Rasmus Schultz)

--14dae9cfcb9ae4a81104d60194c2
Content-Type: text/plain; charset=ISO-8859-1

This is a not a feature request, just a note on something that occurred to
me.

Since there is talk of native support for annotations again, it occurred to
me that part of the problem that every userland implementation and proposed
syntax deals with, along with native implementations in other languages, is
that of convenient short-hand syntax for construction and initialization
(of annotation objects.)

A constructor is a method with arguments, so a single familiar syntax
really could (perhaps should) be applicable in all of those cases.

How about something like this?

    class Foo
    {
        public $bling;

        public function __construct($bar, $baz)
        {
            ....
        }

        <Text{ label='Bar'; description='.....'; }> // (sample annotation)
        public function setName($first, $last)
        {
            ....
        }
    }

    $test = new Foo({ bar='bar'; baz=123 }) { bling = 'wibble' };
    // equivalent to:
    // $test = new Foo('bar', 123);
    // $test->bling = 'wibble';

    $test->setName({ last='Kong'; first='Donkey' });
    // equivalent to:
    // $test->setBar('Donkey', 'Kong');

So in other words, a unified syntax for named (constructor and method)
arguments, and property-initialization with the "new" keyword - all of
which could be statically checked (in IDEs), as could the property-values
for an annotation instance.

This could mitigate a lot of crappy stuff you see in (even the leading)
frameworks right now, where far too frequently, initialization and
configuration, as well as "named arguments", are implemented as nested
arrays, to which you cannot apply any kind of static analysis.

Proposed annotation syntaxes (and some syntaxes in other languages)
typically address this issue by introducing special syntax for annotations,
which are a good example of where property-initialization is heavily used
and benefits greatly from static checking, auto-complete in IDEs, etc.

Just throwing that thought out there. Try not to get hung up on the syntax
in the example above, I just came up with something on the spot, just to
provide some context.

</flamebait>

--14dae9cfcb9ae4a81104d60194c2--