ColaPHP 2.0 α released

The size of the Framework file is reduced from 30% kb to kb, and the amount of code is reduced by. The basic functions are not reduced, mainly because many member variables are made public and the set/get method is greatly reduced, in addition, some code is reconstructed, especially some code that cannot be viewed or changed. Another obvious change was to change Com to Ext. The previous idea was Component. Some friends reported that the meaning of Com is unclear and easy to misunderstand. I also realized that the word "Component" is too big, just rename Ext (Extended Extension), which is a little simpler, with core + Extension. A good naming code is half done. Of course some people think Ext is also obscure, and it feels better now. I would like to share with you two interesting things during this 2.0 development: 1) the returned value was mentioned on twitter a long time ago that I wanted to change all the returned values to {'code': 0, 'data': xxx}. During this development, I was hesitant to change all the returned values to this type. PHP is not a fully object-oriented language. At least it cannot reload the _ bool _ method like python. In this way, I cannot directly judge the return value, if ($ obj-> foo ($ bar) {// do something} returns an array, the code should be changed: $ result = $ obj-> foo ($ bar); if (0 = $ result ['code']) {// do something} doesn't like it very much, if a line of code is added, it does not conform to the thinking of "lazy" programmers. It will adjust the "nerves" of many people ". Recently, I also like the error handling method, returned data, and error information in the Go language. Therefore, most of the returned values of ColaPHP are converted to the return operation value. If the return value fails, false is returned, however, an error member variable is provided to quickly obtain the error message: if ($ obj-> foo ($ bar )) {// do something} else {var_dump ($ obj-> error);} is a trade-off solution, but it is satisfactory. 2) For Exception Handling, ColaPHP 1.x prefers to throw exceptions. All errors that affect the process are thrown exceptions, which are simple, crude, and effective. When developing 2.0, I hesitated to provide user-friendly error information. I didn't want users to try {} catch {} and so on as soon as they used ColaPHP code. The process was broken, give it to programmers (this is also one of ColaPHP's Design Philosophy ). After hesitating for a long time, google posted some articles on PHP Exception Handling Methods. When can we see Laruence's exception ?, The trade-off is that it is better to directly throw it. Compared with try-catch, it is harder to endure the code that is full of if-else. The general feeling is that ColaPHP 2.0 is back to its first appearance, which was originally simple.