Hi Dmitry,
Last time we discussed was this one: https://wiki.php.net/rfc/annotations
The ideal one was the version before:
https://wiki.php.net/rfc/annotations?rev=1300089833
To have this in core, we need to step back and re-evaluate how we could
achieve 80% minimum. My original proposal was trying 95%, too much.
We could get 80% by having a simpler implementation, something like this:
<[ new Foo() ]>
class Bar
{
}
And all it would be required is 2 new methods as part of Reflection classes.
The example could be translated into this:
$bar = new \ReflectionClass('Bar');
$bar->setMetadata([ new Foo() ]);
var_dump($bar->getMetadata());
array(1) {
[0] => object(Foo)
}
Does that sound reasonable? It would allow us to achieve "nested
annotations".
However, it would not achieve a bunch of other things, like named
parameters (you couldn't only do one or two as a constructor params...
Foo(null, null, 'value') would be seen everywhere).
We forget about inheritance, so metadata wouldn't be propagated to
inherited classes, methods or properties.
Also, if we implement in important Reflection structures, that would
incredibly improve its power, such as: ReflectionClass, ReflectionProperty,
ReflectionMethod, ReflectionParameter and ReflectionFunction.
I think this is more reasonable than my original proposal, addresses 80% of
use cases and still help all projects around.
Named parameters would be my next battle then... =D
[]s,
On Fri, Feb 6, 2015 at 9:17 AM, François Laupretre <franc...@tekwire.net>
wrote:
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
>
> > Personally, backward compatibility is not too important.
> > PHP5 is dead by PHP 7.2 release... This is the reason why.
> > It's only 3 years later, only 2 years later after PHP 7.0 release.
>
> That's where we disagree, as I think it's most important.
>
> Thinking that PHP 5 is dead in 3 years is extremely naïve IMO. You
> probably didn't live the PHP 4/5 migration but I guess we won't have more
> than 30 % of production servers under PHP 7 in 2018, just due to the delays
> of distros, hosting companies, and others.
>
> Now, suppose you're distributing a library or a framework, like Symfony,
> Doctrine, etc. Someone tells you : "Here's the new DbC feature. You can use
> it but this implies splitting your code to two independent branches and
> maintain them in parallel until you have no PHP 5 customer anymore.". What
> do you think you'll do (or won't do) ?
>
> @Pierre,@Dmitry : you have a better vision than mine on the migration
> process. What's your opinion on forcing software developers to maintain two
> separate branches ?
>
> Once again, the conditions in @assert lines ARE PHP code. There's no new
> syntax. There is no real difference between writing 'assert(<condition>)'
> and '@assert <condition>', especially if the require/ensure blocks should
> contain 'assert' statements only.
>
> > What I believe is not important to you. I could be wrong.
>
> It is important. As I may be wrong too.
>
> Cheers
>
> François
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
