Процедурный подход в PHP и ОО. Налицо несовместимость синтаксиса.

[Духовность™]

Процедурный подход в PHP и ОО. Налицо несовместимость синтаксиса.

Можете приготовиться кидать в меня тапки, ибо сейчас я замахнусь на самое святое.

В PHP реализовали возможность писать на ООПрограммировании. Классы, функции классов, фитчи в виде SPL.. а стал ли сам язык удобным для написания ОО-программ? Я думаю, что ни капли.

Если цитировать википедию, то "По мнению Алана Кея, создателя языка Smalltalk, которого считают одним из «отцов-основателей» ООП, объектно-ориентированный подход заключается в следующем наборе основных принципов 1. Всё является объектом."

Первый и основной принцип - все является объектом. Так же как в реальном мире все является объектом и состоит из объектов. В реальном мире примитивные объекты - молекулы. Из молекул состоит железо, из железа состоят автомобили как наивысшие по своей сложности объекты в цепочке молекула-железо-автомобиль.

Теперь вернемся к PHP. В PHP нет объектов низшего порядка - молекул - простых типов данных. Нет объекта массив, нет объекта число, нет объекта булев тип. Ничего этого на первых этапах создания языка разработчики не сделали. А нужны ли эти объекты? Я думаю, что нужны. И подтверждением этому может служить творение, называемое SPL - Standard PHP Library. Если взглянуть на эту "стандартную библиотеку", то можно сделать вывод, что суть существования этой библиотеки - заплатка для написания программ в ОО-стиле.

Попробую объяснить на примерах. Простой код:

$object->my_array;

возвращает с помощью метода __get массив данных с ключом "my_array" из хранилища объекта $object. Далее, допустим, мне нужно получить переменную этого массива. Что я должен сделать?

echo $object->my_array['key'];

Отлично. А как мне добавить элемент в начало массива $object->my_array? Правильно, нужно писать страшный код - смесь структурного и ОО-подхода:

$temp = $object->my_array;
array_unshift($temp, 'new_val');
$object->my_array = $temp;

можно, конечно, вынести все это в метод класса к которому принадлежит объект $object

$object->append('new_val')

но это не правильно - нельзя писать для каждого класса, возвращающего массив, метод append.
Далее. Допустим, мы возвращаем наш массив с помощью функции foo() и хотим сразу же получить значение под индексом "key":

$object->foo()['key']; // так нельзя, это не JS

ну и так далее. Т.е. налицо конфликт синтаксиса двух подходов.

Теперь взглянем на SPL: класс ArrayObject, который, по идее, должен спасти отца русской демократии.

Теперь мы можем сделать так:

$object->offsetGet('key')

а можем и так:

$object->append('123');

- вообще замечательно!

А ну ка попробуем сделать так:

$object->offsetSet( 'my_array', array('key' => 'value') );

что мы получаем в итоге? А в итоге мы получаем, что значение под ключом "my_array" становится ОБЫЧНЫМ массивом, а не объектом типа ArrayObject. Соответственно, получить значение 'key' массива 'my_array' приходится опять через задницу, ибо не работает вполне логичная конструкция:

echo $object->offsetGet('my_array')->offsetGet('key');

и не работает даже такая конструкция:

echo $array->offsetGet('my_array')['key'];

Зачем нужен ArrayObject? Кто-нибудь мне может объяснить? Какой смысл в этом объекте?

Подозреваю, что костыль ArrayObject как-то надо переделать, что бы вышеупомянутые конструкции работали. Т.е. на базе одного костыля мы делаем другой костыль. Замечательно! И это называется SPL!

У меня есть свой костыль - самописный ArrayObject, который легко делает такие вещи:

$cvar = new Cover_Var( array('value1', 245, 'my_array' => array('key' => 'value2')) );

echo $cvar->item(0); // value1

echo $cvar->my_array->key; // value 2

echo $cvar->my_array->count(); // 1

echo $cvar->my_array->append('привет, PHP!')->item(0); // привет, PHP!

echo $cvar->my_array->count(); // 2

беда только в том, что этот костыль, созданный для удобства работы, несоизмеримо долго выполняется, ибо написан на PHP, а не является частью ядра языка.

И таких примеров у меня накопилось достаточно много. Если я не прав - поправьте меня, но я не понимаю, как на PHP можно писать нормальные приложения, у которых не было бы конфликта синтаксиса двух подходов.

 

[C_TIGER]

if($arr['var'])
Notice
>>1. Всё является объектом.
плохой довод
>>созданный для удобства работы
да уж
>>
И таких примеров у меня накопилось достаточно много. Если я не прав - поправьте меня, но я не понимаю, как на PHP можно писать нормальные приложения, у которых не было бы конфликта синтаксиса двух подходов.
<<
думать нужно не о синтаксисе, а о эффективном решении задачи которая стоит
>>
А нужны ли эти объекты? Я думаю, что нужны.<<<

давайте ещё типизацию строгую в скрипты запихаем =)

 

[Духовность™]

if($arr['var'])

это что?

думать нужно не о синтаксисе, а о эффективном решении задачи которая стоит

какая тут к черту эффективность?

$temp = $object->my_array;
array_unshift($temp, 'new_val');
$object->my_array = $temp;

давайте ещё типизацию строгую в скрипты запихаем =)

http://php.net/manual/en/language.oop5.typehinting.php

 

[AmdY]

объект, это не то, что создаётся посредством new что_то_там_за_класс, ООП это не программирование классами.

<?
//модель
function getUser() {
return array('name'=>'вася', 
    'year' => 18
);
}
//контроллер
function userSay() {
$user= getUser();
return "Меня зовут {$user['name']}, мне {$user['yaer']} лет";
}
//вид
?>
<p><?=userSay()?></p>

 

[C_TIGER]

Так же как в реальном мире все является объектом<<<
нельзя сравнивать линейную абстракцию с объёмной, многомерной, динамической системой

-~{}~ 16.02.10 01:58:

triumvirat
1. условие, даст ошибку. арэйобжект нет
2. не знаю, я об этом не говорил. пар-тры которыми вы будите оценивать "эффектиность" задаёте себе вы сами. точнее задаёт задача

 

[Духовность™]

объект, это не то, что создаётся посредством new что_то_там_за_класс, ООП это не программирование классами.

я знаю, но в данном случае это звучит как отмазка. Вот рабочий код контроллера:

if ($id = $this->request->getGet()->id)
{
    $this->user = $this->user_mapper->findById($id);
// ...

в данном случае как мне прикажете этот код переписать, что бы "думать не о синтаксисе, а о эффективном решении задачи которая стоит " (с) C_TIGER ??

 

[C_TIGER]

я же сказал что вы сами определяете критерии эффективности.

 

[Fortop]

Re: Процедурный подход в PHP и ОО. Налицо несовместимость синтаксиса.

Автор оригинала: triumvirat
В PHP нет объектов низшего порядка - молекул - простых типов данных

А они нужны? Зачем?

Автор оригинала: triumvirat
А ну ка попробуем сделать так:
$object->offsetSet( 'my_array', array('key' => 'value') );
что мы получаем в итоге? А в итоге мы получаем, что значение под ключом "my_array" становится ОБЫЧНЫМ массивом, а не объектом типа ArrayObject. Соответственно, получить значение 'key' массива 'my_array' приходится опять через задницу, ибо не работает вполне логичная конструкция:echo $object->offsetGet('my_array')->offsetGet('key');

Ээээ, уважаемый, если Вы делаете через одно место - то виноват ли в этом ArrayObject? Вы же САМИ захотели чтобы был array(), а не ArrayObject. И в этом теперь виноват PHP?

$object->offsetSet( 'my_array', new ArrayObject(array('key' => 'value') ));

Слабо?

Более того
Это одоробло

echo $object->offsetGet('my_array')->offsetGet('key');

хуже читается чем

echo $object['my_array']['key'];

А вот так все чудно работает.

$obj = new ArrayObject();
$obj['key'] = new ArrayObject();
$obj['key'][] = 3;
$obj['key'][] = 1;
$obj['key'][] = 2;
$obj['key']->asort();
var_dump($obj);
var_dump($obj['key']);

но я не понимаю, как на PHP можно писать нормальные приложения, у которых не было бы конфликта синтаксиса двух подходов.

А просто не пользуйтесь синтаксисом подхода которого не понимаете. Пользуйтесь чем-то одним и тогда не будет конфликта подходов.

Проблема в том, что PHP дает много свободы, и есть категория людей, которым свобода несколько мешает.

 

[C_TIGER]

я как перфекционист в общем случае думаю о пр-ти. переписал бы всё при помощи стандартных фун-й без объектов

-~{}~ 16.02.10 02:09:

Fortop
>>>Проблема в том, что PHP дает много свободы, и есть категория людей, которым свобода несколько мешает.
+1
я бы сказал даже слишком много

 

[Fortop]

C_TIGER
Вопрос не в самой свободе.
Вопрос в том, что конфликт синтаксиса таки имеет место быть.

Я например категорически не перевариваю геттеры/сеттеры, но если coding style команды установлен с их использованием, то писать в другом стиле - банально неудобно причем и тебе и другим. Поэтому берешь и пишешь и геттеры и сеттеры, просто потому что так эффективнее.

 

[Духовность™]

Вы же САМИ захотели чтобы был array(), а не ArrayObject. И в этом теперь виноват PHP?

Я имел в виду, что ArrayObject фактически представляет собой объект-массив с методами, идентичными функциям для работы с простыми массивами: ksort, uasort, uksort и т.д. И вполне было бы логично сделать так, что бы ArrayObject принимая массив делал бы его рекурсивно объектом такого же типа - ArrayObject. Ровно на таком же принципе основана идея по реализации extends-объекта ArrayAccess (http://ru2.php.net/manual/en/class.arrayaccess.php) с его абстрактными методами.

хуже читается чем

echo $object['my_array']['key'];

отвратительно читается. Нельзя имитировать работу с объектом как с массивом (ровно как и наоборот и в любых других комбинациях), это порождает кучу путаницы - проверено на собственном опыте.

 

[grigori]

>это порождает кучу путаницы
дай пример путиницы, plz

 

[Fortop]

И вполне было бы логично сделать так, что бы ArrayObject принимая массив делал бы его рекурсивно объектом такого же типа - ArrayObject

Ну как бы это не совсем логично. Код делает ровно то, что от него требуется. Если есть желание изменить поведение - наследуемся и пользуемся наследником.

Да-да! от ArrayObject можно отлично наследоваться

Нельзя имитировать работу с объектом как с массивом

Читается как раз лучше
А проблемы путаницы...
я и не хочу объект как таковой. Меня вполне устраивает массив, который может контролировать свою структуру

 

[Духовность™]

дай пример путиницы, plz

что значит дай пример? в реальном коде имитация массива приводит к банальному затруднению понимания написанного. Особенно если человек до этого не имитировал объекта как массив. Играться так с синтаксисом - глупо. Для объектов есть один синтаксис, для массивов другой. Когда массив и объект меняются местами грубо говоря, лично меня это зачастую вводит в ступор.

 

[grigori]

если юзать объект массив как массив - затруднений быть не должно
внутренняя структура не должна влиять
поэтому и "дай пример"

 

[Fortop]

triumvirat
Так в чем вопрос?

Хотите строгих типов - их есть в PHP [m]spl-types[/m]
Хотите массив-объект - [m]ArrayObject[/m].

Сами жалуетесь, что

отвратительно читается. Нельзя имитировать работу с объектом как с массивом

И при этом пользуетесь array()

Вы когнитивный диссонанс у себя не наблюдаете?

 

[fixxxer]

PHP - гибридный язык с множеством проблем роста. Хочешь everything-is-an-object - Ruby в руки.

Я Капитан?

 

[Духовность™]

поэтому и "дай пример"

на

$error['value']->asort();

- это где-то в середине сценария или даже в отдельном файле.

Что это такое? Массив с объектом у которого есть метод asort или объект возвращающий значение-объект у которого есть метод asort?

Я Капитан?

если не будешь спорить с очевидным, как они, то да

Хотите строгих типов - их есть в PHP spl-types

ААААххахахах!! Жесть=)

Да-да! от ArrayObject можно отлично наследоваться

я посмотрю, насколько наследник будет быстро работать...

 

[Fortop]

Что это такое? Массив с объектом у которого есть метод asort или объект возвращающий значение-объект у которого есть метод asort?

Какая разница?
Вполне очевидно, что в ключе 'value' лежит объект. Чему это мешает?

я посмотрю, насколько наследник будет быстро работать...

А тут нечего смотреть. Когда нет аргументов выползают аргументы в стиле выше.
А работать будет одинаково быстро Это кстати о птичках.

ЗВЕЗДЕЦ!! Костыли!!!1!1!!!

Пока я склоняюсь к мнению, что вы просто не умеете готовить. Если сумеете убедить меня в обратном - буду искренне рад.

 

[AmdY]

fixxxer почему ты уже не первый раз указываешь на ruby, как на хорошую ООП альтернативу? неужели он лучше python в этом плане? Можно развёрнутый ответ, если всё же луше?