Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type;
        b=iKLuYvCoyeamtnyzPCOSIVtGkax8V6ODy8ryNaBIPbrS34RchdVDOeVGNlxHBcS0rw
         j1U/2jTWieJOaEAwXCTIwKtNHLguh4JcRfZg1fBE3XwQeSOrdQaeSP5dkDGHUWmZlSzP
         zPyVJBgmXS/t3Fj9m6E/pKIRwibbl2mPxo/CI=
MIME-Version: 1.0
Reply-To: RQuadling@googlemail.com
In-Reply-To: <4CE335CE.90904@sugarcrm.com>
References: <AANLkTik703Bky+ZtjdzBMY8tr97m34jDSSMyoB9opJKR@mail.gmail.com>
 <887FE7CFF6F8DE4BB3A9535F53AFD06A2C59B588@il-ex2.zend.net>
 <AANLkTin9BQj4VhwBBBOYkhDV8uFrmgPvMTZ3L8LgdSBg@mail.gmail.com>
 <887FE7CFF6F8DE4BB3A9535F53AFD06A2C59B6A0@il-ex2.zend.net>
 <AANLkTikOsWcA5X_M2KuM-4L2YtTY-Y6VqV3X_b4zNeFM@mail.gmail.com>
 <887FE7CFF6F8DE4BB3A9535F53AFD06A2C59D788@il-ex2.zend.net>
 <op.vl9qo0kpidpuyk@cataphract-old> <4CE335CE.90904@sugarcrm.com>
Date: Wed, 17 Nov 2010 09:58:03 +0000
Message-ID: <AANLkTi=-4-y5203hA-pK9Wt6jXKAm3tPqPU9gyA38J4A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, Zeev Suraski <zeev@zend.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
From: rquadling@gmail.com (Richard Quadling)

On 17 November 2010 01:54, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> I would have no trouble accepting a rejection of annotations on the actual
>> merits, but the interminable sequence of comparisons to phpdoc make it
>> clear to me that people just don't realize the potential of annotations.
>
> People do realize the potential, what you and many "+1" voters seem to not
> realize is the cost. You propose to add new syntax into PHP which is
> completely different from all other syntax constructs in PHP - different
> instantiation syntax, different method parameters syntax.
> It's a full micro-language inside PHP. We discussed it already, but somehow
> it failed to register.
>
>> Yes, it is new syntax and by itself that is undesirable. However, I see
>
> The problem is not new syntax per se. The problem is new syntax for things
> that already have old syntax.

I'm a +1 in terms of PHP having support for meta data.

The issues that seem to be raised so far are:

1 - New syntax / micro-language / etc to learn
2 - Parser performance and new parser to code/develop/test
3 - APC cacheing of meta data.

What if the meta data is just more PHP code? We all know PHP. The
parser already works. APC already gets it op-codes. Nothing
significantly new to learn/develop/test.

With DocBlocks, the comments are relative to the element they are
describing and are placed immediately before the item in question,
with the exception of a file level docblock.

Keeping with that, what if there was 1 new keyword; something like
annotate or annotation.

This keyword would operate in the same was as class.

I don't know what the content of the annotation would be, but if I was
asked to try and describe what an annotation looks like, based upon
what I've seen, it looks like a set of consts. The items don't change,
just like a const. Please bear in mind that I've not used annotations
beyond docblocks and wsdl generation.

So, maybe something like this ...

<?php
annotate __FILE__ {
 const Author = "Richard Quadling";
 const Category = "Richard's Framework";
 const Copyright = "Copyright (c) 2005-2010 Richard Quadling"
 const Package = "Win32";
 const Subpackage = "Service";
 const Version  = 1.0;
}

annotate Win32_Service {
 const Title = "Win32_Service";
 const Description = "This abstract class allows for the installation,
uninstallation and execution of a PHP script as a Microsoft Windows
Service.";
 const Abstract = True;
 const Package = "Win32";
 const Subpackage = "Service";
 const Version  = "$Id: Service.php,v 1.0.53 2010-11-15T12:49:48+00:00
RichardQ $";
}
abstract class Win32_Service extends Task {
....
}
?>

From this, I think there would need to be a few changes.

1 - "annotate" may not be enough, so maybe annotateFile,
annotateClass, annotateFunction, annotateXxxxx, where xxxx is the
element type being annotated - possibly/probably too much.
2 - Because some of suggestions on what annotations need to support
includes nested data, a const would need to be allow for an array to
be assigned. Personally, I think supporting a const array is a pretty
useful idea.

The advantages that I see here are hopefully fairly obvious.

1 - No new significant core changes. Essentially a new type of class.
If annotateFile is the preferred route, then this obeys the rules like
namespaces. Only 1 per file. As would annotateNamespace.
2 - The syntax is extremely familiar.
3 - There is nothing significantly new in the parser (naive assumption).
4 - APC would get the data in the same way as if it was a class or a namespace.
5 - Adding new elements to the annotation would involve absolutely no
changes to core. You want to add meta data describing the COBOL
picture format of a parameter or the regex validation rule that will
be used, then fine. Nothing in the engine will change.


-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY