PHP의 기본 유형 메소드-PHP 튜토리얼-php.cn

서론

처음으로 다른 사람의 글을 번역하고 CET-4 영어로 번역해봤습니다~~囧, 부적절한 부분이 많을 수 있으니 댓글 달아주세요. 적절한 것을 생각하지 마세요) 번역, 원문과 매우 낮은 번역을 모두 게시했습니다.

이 글을 번역하는데 3박 1일이 걸렸습니다~. 먼저 기술적인 측면을 먼저 이해한 뒤 번역을 하게 됩니다~

하는 목적 이것은 한편으로는 영어를 훈련하고 해외에서 상대적으로 새로운 기술 아이디어를 배우는 것입니다.

이 기사에서는 주로 PHP의 기본 유형에 대한 객체 지향 작업 구현에 대해 설명합니다. 이는 PHP의 불규칙한 함수 이름 지정, 불규칙한 매개변수 순서 및 낮은 가독성 문제를 해결하기 위해 확장을 통해 구현됩니다.

ZEND 엔진에서 객체지향 메소드를 호출할 때 해당 처리 함수를 변경하여 확장을 구현합니다. 객체지향 호출자의 유형을 판별하는 함수를 등록합니다. IS_STRING이면 사용자 정의 처리를 계속합니다. ZEND 기본 처리 함수로 돌아가서 아래 설명을 보세요

HOOKPHP 코드

PHP는 해석된 언어이며 코드는 다음과 같은 방법으로 중간 바이트코드로 변환됩니다. ZEND 엔진이 구문 분석하고 실행합니다. PHP는 중간 바이트코드 OPCODE를 호출합니다. 각 OPCODE는 ZEND 하단의 처리 함수에 해당합니다. ZEND 엔진은 최종적으로 이 처리 함수를 실행합니다. HOOK 기능을 구현하려면 HOOK OPCODE에 해당하는 처리 기능만 변경하면 됩니다.

PHP의 기본 유형에 대한 객체 지향 접근 방식

며칠 전 Anthony Ferrara는 PHP의 미래에 대한 몇 가지 생각을 썼습니다. 나는 그의 요점 대부분에 동의하지만 전부는 아닙니다. 이 문서에서는 문자열 및 배열과 같은 기본 유형을 메서드 호출이 수행될 수 있는 "의사 개체"로 위장하는 특정 측면에 중점을 둡니다.

"의사 개체"가 필요한 이유를 알아보기 위해 몇 가지 예부터 시작하겠습니다.

<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>

로그인 후 복사

여기서 $str는 일반 문자열이고 $array는 일반 문자열입니다. 배열 - 객체가 아닙니다. 우리가 한 일은 메소드를 호출할 수 있도록 좀 더 객체와 유사한 속성을 제공한 것뿐입니다.

위의 기능은 손이 닿지 않는 것이 아니라 이미 존재한다는 점에 유의하세요. PHP 확장 scalar_objects를 사용하면 기본 PHP 유형에 객체 지향 메서드를 정의할 수 있습니다.

네이티브 유형에 객체 스타일 호출 메서드를 도입하면 많은 이점을 얻을 수 있으며, 아래에 나열하겠습니다.

API를 더욱 단순화할 수 있는 기회

아마도 PHP에 대한 가장 일반적인 불만 사항은 표준 라이브러리의 함수가 일관되지 않고 불명확하며 이름이 불분명하고 매개변수가 일관되지 않고 순서가 잘못되었다는 것입니다. 몇 가지 일반적인 예:

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

//很不清晰的命名
strcspn
strpbrk

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

로그인 후 복사

이러한 문제가 지나치게 강조되는 경우가 많지만(우리는 통합 개발 환경을 갖추고 있음) 상황이 상당히 좋다는 점을 부정하기는 어렵습니다. 또한 많은 함수가 이상한 이름을 넘어서는 문제를 제시한다는 점에 유의해야 합니다. 종종 극단적인 경우의 동작이 완전히 고려되지 않아 호출 코드에서 특수한 처리가 필요합니다. (문자열 함수의 경우 극단적인 경우에는 일반적으로 빈 문자열이나 문자열 범위 밖의 오프셋이 포함됩니다.)

일반적인 제안은 함수 이름과 매개변수 순서를 통합하기 위해 PHP6에 수많은 별칭을 구현하는 것입니다. 따라서 stringpos(), stringreoplace(), stringcomplement_span() 또는 이와 유사한 것이 있습니다. 개인적으로 (그리고 이것은 많은 php-src 개발자들의 의견인 것 같습니다) 이것은 나에게 거의 의미가 없습니다. 이러한 함수 이름은 이제 PHP 프로그래머의 기억 속에 깊이 각인되어 있어 중요하지 않은 외관상 변경 사항을 구현하는 것은 가치가 없어 보일 수 있습니다.

반면 원시형에 대한 OO API의 도입은 새로운 패러다임으로의 전환에 따른 부작용으로 API 재설계의 기회를 제공합니다. 또한 이를 통해 이전 API의 예상 출력을 고려하지 않고도 처음부터 시작할 수 있습니다. 두 가지 예:

저는 $string->split($delimiter) 및 $array->join($delimiter)과 같은 메소드를 갖고 싶습니다. 이는 일반적으로 함수에 대해 허용되는 이름입니다(explode 및 implode과는 달리). 반면에 이렇게 동작하는 stringsplit($delimiter) 메서드가 있다면 매우 역겨워할 것입니다. 기존 str_split 함수가 완전히 다른 작업(그룹화)을 수행하기 때문입니다.
물론 오류 보고에 예외를 사용하는 새로운 API가 마음에 듭니다. 객체 지향 API이므로 이름이 변경된 API에도 예외가 당연히 사용됩니다. 이는 모든 프로그램 기능에서 오류 처리에 경고를 사용하는 현재의 관례에 위배됩니다. 이것은 확정된 것은 아니지만 실제로 피하고 싶은 논란의 여지가 있는 점입니다. 기본 유형 구현 객체 지향 API의 주요 동기: 처음부터 시작하면 합리적인 API 디자인을 구현할 수 있습니다. 물론, 나는 이 변화의 모든 이점을 알지 못한다. 객체 지향 구문은 아래에서 설명하는 더 많은 이점을 제공합니다.

提高了可读性

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

<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中所看到的其中一个改进。我也许会为我的那个方向的计划写另外一篇文章。