Я вот подумываю уходить от простых типов переменных, как integer, string в PHP.
А вместо них создавать объекты: Integer, String.

Это неплохо работает в помощи метода: __toString().

Приемущества очевидные:

1. Method chaining
$objString->method_a()->method_b()->method_c();

2. Type Hinting
function foo(String $string) {}

Что делают с людьми кризис и нервное напряжение...

Рецепт: больше витаминов в пище, прогулки на свежем воздухе и спать, больше спать.

Crazy,
на практике я давно использую вместо родных PHP массивов - свой класс. В этом случае, результат SQL запроса выглядит лаконично:

Также, номер телефона хорошо держать не в обычной переменной: $phone = '123-456-7890', а в специальном объекте.
Объект не допустит неверных входных данных, например: $phone->set('bla-bla') - выдаст ошибку.
Программе не надо знать что $phone это String (инкапсуляция).
Исходя из этих предпосылок, я решил что простые типы тоже можно заменить на объекты. Мне это уже помогло сделать код компактнее.

Вместо:

Я могу писать так:

Единственный недостаток - нагрузка процессора. Но ИМХО она возрастет линейно (liniar):
O(NC), где С - коффициент, во сколько раз объект медленнее переменной простого типа.
см. Big O Notation

А теперь отделим мух от котлет.

Даже если забыть о существовании "in_array", то ничто не мешает писать так:



...а равно -- писать:



...не создавая никаких врапперов вокруг массивов.

Есть такая штука: структурное программирование. Которое никто не отменял. И никто не заставляет выбирать между ООП-кодом и грязным неструктурированным кодом -- есть и другие альтернативы.

То же ООП нужно использовать правильно. Например, создание класса Phone вполне может быть разумно, если он соответствует сущности предметной области. В отличие от создания бессмысленного враппера вокруг абстрактного понятия "строка".

Создание скоих врапперов для примитивных типов не решает ни одной задачи, которую не решает банальное структурное программирование в форма тупого создания необходимых функций.

Про O-большое -- спасибо, посмеялся.

Да, эти термины более точны: класс-враппер и примитивный тип.

Но Method chaining работает только с объектами.

Код будет работать только если fetchArray() вернет объект (например Array).
Без класса-враппера тут не обойтись.

Врапперы возможно не решают задач, которые не решает структурное программирование,
но правильное их использование делает PHP программу более читабельной. Это и есть моя цель.

Определенно. Но это вовсе не означает, что возвращенный объект должен быть враппером над array. Здравый смысл говорит, что при нормальном проектировании метод должен называться не fetchArray, а fetchRow и возвращать объект, представляющий строку выборки. И array здесь ни при чем.

Что касается читабельности, то здесь помогает правильное проектирование, а не слепое оборачивание примитивов в объекты.

Crazy писал(а):

Здравый смысл говорит, что при нормальном проектировании метод должен называться не fetchArray, а fetchRow и возвращать объект, представляющий строку выборки. И array здесь ни при чем.

Но мы должны иметь возможность производить итерацию объекта Row.
Поэтому логично предположить что он наследует Array.

Только что нашел что PHP имеет класс: ArrayObject.
и какие то экспериментальные разработки, вроде Integer объекта.

AlexShop писал(а):

Но мы должны иметь возможность производить итерацию объекта Row. Поэтому логично предположить что он наследует Array.

Первое утверждение неверно. Второе утверждение не следует из первого. И вот почему:

1. Нам нужно иметь возможность итерирования по выборке. При этом Row является одним из элементов выборки.

2. Для итерирования нам нужно иметь возможность проверить наличие следующего элемента и перейти к нему. Хорошим примером организации итерирования по выборке является RecordSet из JDBC. Там для этого введен единственный метод next():boolean. Никакие массивы здесь не нужны.

Соответственно, если отбросить примеры очевидно неуместного использования, то врапперы вокруг примитивных типов дадут нам исключительно syntactic sugar. Не имею ничего против того, чтобы кто-то лично для себя такое создавал. Вот только нужно осознавать, что ни на скорости разработки, ни на читабельности кода они существенно не сказываются.

Оказывается термин уже для этого есть: syntactic sugar.
Опробую немного на практике. К сожелению несовместимости уже выявляются.

Например этот код дает ошибку (object to Integer conversion):

Можно заменить на такое (к примеру):

Затея - ерунда. Потому что много несовместимостей с существующим кодом и вообще с языком:

if else - не работает: любой объект (в том числе и String) оценивается как TRUE.
Объект Integer не будет работать с циклами как: for

Поддержка примитивных типов ввиде объектов врятли пойдет дальше существующей функции __toString().
В PHP6 осознанно не будут это развивать, потому что это Weak typed язык:
http://www.php.net/~derick/meeting-note … tive-types

Наверно поэтому нет Type Hinting как: function foo(String $string) {}

Сама по себе __toString полезная функция, например для таких объектов как Phone (см. выше).

Вообщем я успокоился.

P.S. Но объект массив - имхо это очень удобно