I think the original proposal is more consistent then the simple one. Most probably, it just came not in right time. In case @internals really like annotations and we came to consensus how it should look like, I may take care about efficient implementation.
Thanks. Dmitry. On Fri, Feb 6, 2015 at 6:19 PM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > 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 >
