On 17 November 2010 01:54, Stas Malyshev <smalys...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
