Hi Dmitry, Actually the RFC was approved by 1 or 2 votes more than needed, but the overall response from core maintainers was that it was overly complex, adding features the language did not support until that point (named parameters, short array syntax as examples), it was broken with the proposed opcache merge (was not a trivial fix IIRC) and memory expensive.
I think a simpler approach could work now as I suggested in previous messages. It does not add new features besides annotations itself. We'd still have to discuss about the memory usage and where the metadata class instances should be placed. []s, On Fri, Feb 6, 2015 at 10:12 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Dmitry, > > Doc comments are terrible. I really want you to spend some time looking at > what we had to do inside of Doctrine Annotations to make it work. We have > to token_get_all() the file to be processed and track for "use"s to allow > importing inside of doc blocks. We also had to build a top-down recursive > parser to make it work... don't you think it's too much? As one of the > library maintainers, I do, by heart. > > We have until Mar 15 to work on something and propose. I can work on it > without any problems, but as an enthusiast of PHP, it's very frustrating > that I spend time to make PHP better and none even care to review PRs or > simply ignore messages on php-internals. If anyone compromise to review, > I'd do my best to get it ready yesterday if it was possible! > > Thanks, > > On Fri, Feb 6, 2015 at 9:40 AM, Dmitry Stogov <dmi...@zend.com> wrote: > >> I see your point, and, of course, it makes sense, but it also means that >> no >> new PHP7 features might not be used in these frameworks and libraries for >> a >> long time. Should we stop add new features in major releases? >> >> As I said, according to DbC, I'm not sure if it should be defined on >> language level. Doc comments or annotations with external tools might be >> good enough. >> >> Thanks. Dmitry. >> >> On Fri, Feb 6, 2015 at 5:17 PM, 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 >> > >> > >> > > > > -- > Guilherme Blanco > MSN: guilhermebla...@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
