Native type methods in PHP

Introduction

This is my first time translating someone else’s article, using CET-4 English level to translate~~囧, there may be many inappropriate places, feel free to comment (there are some places I really can’t think of appropriate translations, I will post them at the same time The original text and my own very low translation).

It took me 3 nights and 1 noon to translate this article~. I first figured out the technical aspects and then what to say, and then translated it~

The purpose of this is to practice my English on the one hand, and to learn some foreign language on the other hand. Relatively new technical ideas.

This article mainly talks about implementing object-oriented operations on native types in PHP, which is implemented through extensions to solve the problems of irregular function naming, irregular parameter order, and low readability in PHP.

The extension is implemented by changing the corresponding processing function when calling object-oriented methods in the ZEND engine. Register a function to determine the type of the object-oriented caller. If it is IS_STRING, continue custom processing, otherwise return to the ZEND default Processing function, take a look at the explanation below

HOOKPHP code

PHP is an interpreted language, and the code is translated into intermediate bytecodes and parsed and executed by the ZEND engine. PHP calls the intermediate bytecode OPCODE. Each OPCODE corresponds to a processing function at the bottom of ZEND. The ZEND engine finally executes this processing function. To implement the HOOK function, you only need to change the processing function corresponding to the HOOK OPCODE.

An Object-Oriented Approach to Native Types in PHP

A few days ago, Anthony Ferrara wrote down some thoughts on the future of PHP. I agree with most of his points, but not all. This article focuses on a particular aspect: disguising native types like strings and arrays as "pseudo-objects" on which method calls can be performed.

Let's start with a few examples to see why "pseudo-objects" are needed:

<code>$str = "test foo bar";
$str->length();      // == strlen($str)        == 12
$str->indexOf("foo") // == strpos($str, "foo") == 5
$str->split(" ")     // == explode(" ", $str)  == ["test", "foo", "bar"]
$str->slice(4, 3)    // == substr($str, 4, 3)  == "foo"

$array = ["test", "foo", "bar"];
$array->length()       // == count($array)             == 3
$array->join(" ")      // == implode(" ", $array)      == "test foo bar"
$array->slice(1, 2)    // == array_slice($array, 1, 2) == ["foo", "bar"]
$array->flip()         // == array_flip($array)        == ["test" => 0, "foo" => 1, "bar" => 2]</code>

Here $str is just an ordinary string, $array is just an ordinary array - they are not objects . All we did was give them a little more object-like properties so they could call methods.

Note that the above features are not out of reach, but already exist. The PHP extension scalar_objects allows you to define object-oriented methods on native PHP types.

The introduction of object-style calling methods in native types also brings many benefits, which I will list below:

An opportunity to further simplify the API

The most common complaint about PHP that I hear most is probably There are inconsistencies and unclear naming of functions in the standard library, as well as inconsistent and out-of-order parameters. Some typical examples:

<code>//不同的函数命名约定
strpos
str_replace

//很不清晰的命名
strcspn
strpbrk

//颠倒的参数顺序
strpos($haystack, $needle)
array_search($needle, $haystack)</code>

While these issues are often overemphasized (we have integrated development environments), it’s hard to deny that the situation is pretty good. It should also be noted that many functions present problems that go far beyond weird names. Often the behavior of edge cases is not fully considered, necessitating special handling of them in the calling code. (For string functions, edge cases usually include empty strings or offsets outside the range of the string.)

A general suggestion is to implement a huge number of aliases in PHP6 to unify function names and parameter order . So we will have stringpos(), stringreoplace(), stringcomplement_span() or similar. Personally (and this seems to be the opinion of many php-src developers) these mean very little to me. These function names are now so ingrained in the memory of PHP programmers that it may not seem worthwhile to implement some unimportant cosmetic changes to them.

The introduction of an OO API for primitive types on the other hand offers an opportunity of an API redesign as a side effect of switching to a new paradigm). This also really allows us to start from scratch without having to consider the expected output of the old API. Two examples:

• I really wish there were methods like $string->split($delimiter) and $array->join($delimiter), these are generally accepted names for function functions ( Unlike explode and implode). On the other hand I would be very disgusted if there was a stringsplit($delimiter) method that behaved like this, because the existing str_split function does something completely different (grouping).
  
• Of course I like the new API that uses exceptions for error reporting. Since this is an object-oriented API, that is automatically given. Exceptions are of course also used with the renamed API. However, this goes against everything now The convention for program functions to use warnings for error handling is not set in stone, but it is indeed a point of contention that I would like to avoid :)

This was my main motivation for implementing a native type object-oriented API: starting from scratch, allowing We implement a reasonable API design. Of course, I don’t know all the benefits of this change. Object-oriented syntax provides many deeper benefits, discussed below.

提高了可读性

程序式的调用一般没有链式调用好。考虑下面的例子：

<code>$output = array_map(function($value) {
    return $value * 42;
}, array_filter($input, function($value) {
    return $value > 10;
});</code>

咋一看，哪个是arraay_map和array_filter各自的使用？(原文：what are array_map and array_filter applied to? )他们调用的顺序是什么？变量$input隐藏在两个闭包之间，函数的书写顺序也和他们实际调用的顺序相反。现在同样的例子使用面向对象的语法：

<code>$output = $input->filter(function($value){
	return $value > 10;
})->map(function($value){
	return $value * 42;
});</code>

我敢说使用这种方式，操作的顺序（先filter在map）和初始输入数组$input更加明显。

这个例子明显有人为拼凑的感觉，因为array_map和array_filter是函数参数顺序颠倒的另外一个例子（这就是为什么输入数组在中间）。再看另外一个输入参数在同一个位置的例子（来自实际的代码）：

<code>substr(strstr(rtrim($className, '-'), '\\', '_'), 15);</code>

在这个例子中，最后面是一连串的额外的参数'_'), '\\', '_'), 15,，很难把这些参数和应用的函数对应起来。把这个和使用面向对象方法的版本做个比较：

<code>$className->trimRight('_')->replace('\\', '_')->slice(15);</code>

这次函数运算和他们的参数紧密的联系在了一起，而且方法的调用和他们的执行顺序相匹配。

另一个来自这种语法的可读性的好处是needle/haystack不明确问题。别名通过引入统一的参数顺序规范让我们解决了这个问题，使用面向对象的API这个问题基本不存在了。

<code>$string->contains($otherString);
$string->contains($someValue);

$string->indexOf($otherString);
$string->indexOf($someValue);</code>

这里哪个部分应用了哪个规则的困惑不复存在了。

多态

目前PHP有提供Contable接口，这个接口可以通过类实现自定义的输出函数count($obj)。为什么需要这个？因为我们PHP的函数没有多态。然而我们方法中确实需要多态：

如果数组实现$array->count()作为一个方法，实际上代码是不会在意$array是不是一个数组的，他可以是其他任何类型的实现count()方法的对象，这基本上给了我们Countable的所有行为，~（原文:This basically gives us the same behavior as Countable, just without the engine hackery it requires.）

这也是一个很一般的解决方案。举个例子，你可以实现一个实现所有字符串类型方法的UnicodeString类，然后可以随便的使用正常的字符串和UnicodeStrings。好吧，至少这还是理论。这很明显局限于那些字符串方法的使用，而且调用级联操作的时候会返回错误(原文:This would obviously only work as long as the usage is limited to just the string methods, and would fail once the concatenation operator is employed)（运算符重载目前只支持内核中的类）。

我仍然有强大的信念希望这个清晰起来，同样应用在数组等上面。通过继承相同的接口，你可有一个和数组行为方式相同的SplFixedArray。(原文:you could have an SplFixedArray behave the same way as an array, by implementing the same interface.)

既然我们已经总结了这个方法的一些好处，让我们也来看看它的问题：

松散的类型

摘抄自Anthony发表的博客：

标量不是对象，但更重要的是他们不是任何类型。PHP依赖一个类型系统，字符串和数字是同一个。系统中许多的灵活性基于任何标量可以很容易的转换为其他标量。

更重要的是，由于松散的类型系统，你不可能在任何时候知道一个变量的类型是哪个。你可以说出你想要他是什么类型，但你不知道他内在的类型是什么。Even with casting or scalar type hinting it isn’t a perfect situation since there are cases where types can still change.

为了阐明这个问题，考虑下面的例子：

<code>$num = 123456789;
$sumOfDigits = array_sum(str_split($num));</code>

这里$num被作为一个字符串数字，被str_split切分后使用array_sum求和。现在试试同样效果的面向对象方法调用：

<code>$num = 123456789;
$sumOfDigits = $num->chunk()->sum();</code>

这里字符串的cheunk()方法被数字来调用。会发生什么？？Anthony建议这样解决：

这意味着所有的标量运算将必然需要对应的标量类型。这将导致需要一个标量有所有的数学方法的对象模型，当然包括所有的字符串方法。真是一个噩梦。。。。。

就像引言中所说的那样，这绝不是一个可接受的解决方法。然而我想我们可以绝对侥幸的逃脱仅仅在那种情况的时候抛出一个错误（异常！）。为了解释为什么这种方法是可行的，让我们看看PHP可以拥有哪些类型。

PHP中的原生类型

除了对象之外，PHP有下面的变量类型：

<code>null
bool
int
float
string
array
resource</code>

现在，我们考虑下上面这些里面的哪些会需要面向对象的方法：我们首先去掉resource，然后在剩下的里面看。null和bool明显不需要面向对象的方法，除非你想进行像$bool->invert()这样无聊的转换。

绝大多数的数学函数使用面向对象的方法也不是很合适。考虑下面几个例子：

<code>log($n)		$n->log()
sqrt($n)	$n->sqrt()
acosh($n)	$n->acosh()</code>

我想你会同意数学函数可读性比函数符号的形式更好。当然存在少许的面向对象方法你可以适当的应用数字类型，比如说$num->format(10)读起来相当的不错。然而，关于这里，对于一个面向对象的数字API不是真正的需要，只有少量的函数你可能需要。（再者来说目前的数学API在命名方面没有太多的问题，而且数学操作相关的命名相当的标准。）

现在剩给我们的只有字符串和数组了，我们已经看到这两种类型有许多很棒的API。但关于松散类型的问题我们所有的必须要做的有哪些？下面是重要的几点：

我们经常性的把字符串视为数字的时候（例如来自HTTP或者DB），这样反过来是不对的：直接将数字作为字符串非常少见。举个栗子，下面的代码将让我们感到困惑：

<code>strpos(54321, 32, 1);</code>

这样将数字视为字符串是一个很怪异的操作，这种情况也ok啊，只需要强制转换一次就好了。使用原来的求和数字的例子：

<code>$num = 123456789;
$sumOfDigits = ((string) $num)->chunk()->sum();</code>

现在我们弄明白了，是的，我们确实想将数字视为字符串。对我来说，这样来处理想这样使用这种技术的地方是可以接受的。

对于数组情况就更简单了：他不会出现讲一个数组操作视为一个其他不是数组类型的操作。

另一方面可以通过标量类型提示改善这个问题（我完全认为在PHP所有的版本都存在——最令人尴尬的问题是现在仍然没有(原文:which I totally assume to be present in any PHP version this gets in - really embarrassing that we still don’t have them））。如果内类型提示string，你获取输入的字符串将会是一个字符串（即使传递给函数的不是——这取决于类型提示实现的具体内容）。

当然了，我并不是暗示这里没有一点问题。由于错误的函数设计，有时候可能会发生未知的类型潜入代码中，例如substr($str, strlen($str))将自作聪明的返回bool(false)而不是string(0) ""。（不过，这个问题仅有substr存在。面向对象的API不存在那个问题，所以你碰不到那个问题。）

对象传递语义

除了若类型的问题之外，还有原生类型伪方法的一个语义的问题：PHP中的对象和其他类型相比有不同的传递语义（某种程度上和引用类似）。如果我们允许字符串和数组进行面向对象的方法调用，他们看起来会和对象很像，那样的话有些人可能期望他们有对象作为参数的传递语义。这个问题在在字符串和数组中都存在：

<code>function change($arg) {
	echo $arg->length();	//$arg looks like object
	$arg[0] = 'x';			//但是没有对象的传递语义
}

$str = 'foo';
change($str);	//$str stays the same

$array = ['foo', 'o', 'o'];
change($array);	//$array stays the same</code>

我们当然将会改变传递语义。首先，在我看来通过值传递来传递像数组这种大的数据结构是一个相当low的想法，我更愿意他们像对象一样传递。然而，那将是一个相当大的突破性的向后兼容，并且那将不易于自动的重构（原文:However, that would be a pretty big backwards-compatibility break and one that’s not easy to refactor automatically）（至少我猜想是这样的。我没有做实验去探索这样一个改变带来的实际影响）。另一方面，对于字符串通过对象方式传递参数将是一个灾难，除非我们让字符串同一时间完全的不可变，放弃目前所有的局部变量的可变性（我个人发现非常的容易——去尝试改变一个Python字符串的一个字节）。

我不知道是否有好的方法去解决这个预期的问题，除了在我们的文档中强调字符串和数组在面向对象的方法中仅仅视作”伪对像“，不是真正的对象。

这个问题可以被扩展到其他的对象相关的特性。例如你可将会问像$string instanceof string这样的是否正确。我还没有确定整个事情的完整走向。也许严格坚持仅仅在面向对象的方法使用，然后强调他们不是真正的对象会好一点。然而也许支持面向对象系统的更深层次的特性也会好点。这个观点应该进一步的思考下。

目前的状态

总而言之，这个方法有许多的问题，但我不认为他们特别重要。同时这个提供了一个很好的机会为我们的基本类型引入简洁明了的APIs，提高代码执行操作时候的可读性（可写性）。

那么这个想法目前的状态是什么呢？从我收集的内容来看，内部的人们不是特别的反对这个做法，但更愿意重命名所有的函数。主要的没有推进这个的原因是API提议~

为了这个目的，我创建了scalar_objects扩展，作为一个PHP扩展实现了这个功能。它允许你注册一个处理各自的原生类型的方法调用的类。看一个例子：

<code>class StringHandler {
	public function length(){
		return strlen($this);
	}

	public function contains($str){
		return false !== strpos($this, $str);
	}
}

register_primitive_type_handler('string', 'StringHandler');

$str = 'foo bar baz';
var_dump($str->legth());			//int(11)
var_dump($str->contains('bar'));	//bool(true)
var_dump($str->contains('hello'));	//bool(false)</code>

不久前，我开始了一个string handler包括一个API说明的工作，但一直没有真正的完成哪个项目（我希望我在不久找到一些重新开始他的动机）。当然也有许多其他项目在为实现这样的APIs而努力。

嗯，这是我想在PHP6中所看到的其中一个改进。我也许会为我的那个方向的计划写另外一篇文章。

引用

原文链接 ： http://nikic.github.io/2014/03/14/Methods-on-primitive-types-in-PHP.html

HOOKPHP : http://netsecurity.51cto.com/art/201407/446430.htm

以上就介绍了PHP中原生类型的方法，包括了方面的内容，希望对PHP教程有兴趣的朋友有所帮助。