ColaPHP 2.0α released_PHP tutorial

The size of the framework file has been reduced from 188KB to 131KB, and the amount of code has been reduced by 30%. The basic functions have not been reduced. This is mainly due to making many member variables public and greatly reducing the set/get methods. In addition, some codes have been refactored, especially some previous ones. It's a bit of code that I can't stand and can't change much.

Another obvious change is to change Com to Ext. The previous idea was Component. Some friends reported that the meaning of Com was unclear and easy to misunderstand. I also felt that the word component was too big, so I changed the name to Ext ( Extension), simpler, core + extension. Half of the good naming code is completed. Of course, some friends think Ext is also obscure, but I feel fine now.

Let me share with you two interesting things during this 2.0 development:

1) Problem with return value

A long time ago, I said on twitter that I wanted to change all return values ​​to {'code' : 0, 'data' : xxx}. This time during development, I was hesitating whether to change all return values. All changed to this.

PHP is not a completely object-oriented language. At least it cannot overload the __bool__ method like python. With such a direct result, I cannot directly judge the return value. It turns out

if ($obj->foo($bar)) {

// do something

}

If you change the return array, the code should be changed to:

$result = $obj->foo($bar);

if (0 === $result['code']) {

// do something

}

I don’t like it very much. One more line of code is not in line with the thinking of “lazy” programmers, and it will adjust the “nerves” of many people.

Recently, I also like the Go language's error handling method, which returns data and error information. Therefore, most of the return values ​​​​of ColaPHP are changed to return the operation value. If it fails, it returns false. However, an additional error member variable is provided to facilitate quick access to errors. Information:

if ($obj->foo($bar)) {

// do something

} else {

var_dump($obj->error);

}

It is considered a trade-off solution, but I am still quite satisfied.

2) Exception handling

ColaPHP 1.x version likes to throw exceptions. Some errors that affect the process will all throw exceptions. It is simple, crude, direct and effective. When developing 2.0, I hesitated whether to give user-friendly error messages. I didn’t want users to try {} catch {} and the like as soon as they used ColaPHP code. The process would be interrupted and left to the programmers’ own control (this is also One of the design philosophies of ColaPHP).

After hesitating for a long time, I googled some articles on how to handle exceptions in PHP. When I saw Laruence’s When should we use exceptions? After weighing it up, I still think it is better to throw it directly. Compared with try-catch, it is more difficult to tolerate being filled with exceptions. If-else code, choose the lesser of two evils.

The overall feeling is that ColaPHP 2.0 has returned to its original simplicity.

http://www.bkjia.com/PHPjc/477832.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/477832.htmlTechArticleThe framework file size has been streamlined from 188KB to 131KB, the code volume has been reduced by 30%, and the basic functions have not been reduced, mainly due to the Many member variables are made public, which greatly reduces the set/get method. In addition, it is redundant...