HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
Example :
<DbC.requires($a > 0);>
<DbC.ensures(__RETURN__ > 0);>
function foo($a)
{
...
How can you know from this that the first expression must be evaluated at
function entry, that the second one must be interpreted when function exits,
let alone the question of __RETURN__ replacement and external switch to
authorize/disable DbC evaluations.
Several people rightly stated that expression would be computed at compile
time. That's a way to solve the scope question as it practically means that
expressions are evaluated in the global scope, but DbC must evaluate its
expressions at runtime. Does it mean we should write '<DbC.requires('$a > 0')>
? Not very intuitive but that's probably the only solution.
Something else : I am not sure I understand, but do you intend evaluating
annotation expressions everytime you parse the file. Or would you provide a
global switch ?
> Any one can use doc-block now and later, but php core won't parse doc-blocks.
> It's a task for external tools.
I understand. Actually, DbC is not the perfect use case for annotations. It
would be fine to find a good use case because neither of DbC, AOP, Doctrine, or
phpdoc fit so well.
There comes my last question : is it so interesting and mandatory to implement
annotations in the core, instead of an extension which would parse doc blocks
when needed, and would return bare strings through a reflection-like API ? I
know most want to put annotations in the core, but what's the real benefit, if
we don't consider performance ? Do we have use cases comparing both approaches ?
The fact that we voluntarily make it incompatible with phpdoc and doctrine
'annotations' saddens me a bit too because people used to the current
'annotation' meaning will have to integrate that a new PHP native 'annotation'
feature, totally different from what they've been using for years. And doctrine
is not an edge-case. If there are good reasons, why not, but I don't see them
yet.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
