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

Fortop · 16 Фев 2010

так о том и речь, что без этого преобразования метода суть всех этих SPL-овских фитч совершенно не ясна

Кому не ясна?

Вы же хотели строгой типизации? Так и ведите себя в соответствии с ней. Ничего и нигде неявно не преобразовывается. Хотите преобразовывать - делайте сами ручками явно или реализовывайте неявный кастинг.
В чем вопрос?

а как иначе объяснить появление SPL и подобных решений?

Т.е. Вы даже не знаете как можно применить классы и интерфейсы из SPL и теперь упорно ищите объяснение для чего они?

Для меня это еще одна возможность, которой я волен пользоваться или забыть о ней.

P.S. Вы обещали "пол страницы речь о стандартных средствах языка. ".
Где это?

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

Духовность™ · 16 Фев 2010

Т.е. Вы даже не знаете как можно применить классы и интерфейсы из SPL и теперь упорно ищите объяснение для чего они?

Я у Вас не спрашиваю, как применять SPL - применять его я умею. Я задаю вполне конкретный вопрос - для чего введена библиотека SPL с кучей её ОО-фитч. И сам же даю ответ - для того, что бы сделать заплатку. Создать на базе personal home page более-менее серьезный язык.

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

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

P.S. Вы обещали "пол страницы речь о стандартных средствах языка. ".
Где это?

Вы игнорируете то, что написано в моем первом посте. Я по моему доходчиво объяснил не состыковку ОО и структурного синтаксиса в PHP.

Пока мы видели лишь жалобы о том что язык несоответствует Вашим желаниям

Ещё раз - читаем первый пост до полного просветления.

Fortop · 16 Фев 2010

triumvirat
Я по моему доходчиво объяснил не состыковку ОО и структурного синтаксиса в PHP.

Вы доходчиво объяснили непонимание того факта что PHP поддерживает две парадигмы. Ничего более Вы не объяснили.

Есть реальность, а есть Ваши выдумки.

Реальность такова, что это работает так, а не иначе. С какого бодуна оно должно работать иначе Вы не объяснили. Более того ничего не сделали для того чтобы работало иначе.

Но зато имеете у себя диссонанс между желаемым и возможным.
И пользуясь синтаксисом процедурного PHP, Вы почему-то удивляетесь что он ведет себе не по-ООПецки

Что Вам мешает не использовать процедурные методы - я откровенно не понимаю.

для чего введена библиотека SPL с кучей её ОО-фитч. И сам же даю ответ - для того, что бы сделать заплатку

Для желающих. Была у людей потребность - ее удовлетворили.
Ровно для тех же целей были введены большинство расширений в PHP.
Но по Вашей дивной логике php_mysql была создана тоже в качестве заплатки...

-~{}~ 16.02.10 13:18:

разработчикам предлагается делать "как хотите".

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

Поэтому смените язык на более подходящий Вашим желаниям. Или напишите свой.

Духовность™ · 16 Фев 2010

PHP поддерживает две парадигмы

которые несостыкуются, да.

С какого бодуна оно должно работать иначе Вы не объяснили.

Я показал вполне конкретные примеры, демонстрирующие, что отсутствие в языке объектов базовых типов данных приводит, по меньшей мере, к уродливому написанию синтаксиса. Несовместимость базовой структурной и Оопарадигмы приводит вот к подобным конструкциям:

PHP:

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

$object->foo()['key'];

Я привел мнение авторитетного человека, относительно того, что считается оо-подходом.

Вы же мне сетуете на "реальность" и фактически утверждаете "не нравится - не ешь". Это философия и демагогия. Это как "не нравится отечественный автором - сделай лучше".

Более того ничего не сделали для того чтобы работало иначе.

ммм... а что я должен был сделать?

Была у людей потребность - ее удовлетворили.

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

Sigorma · 16 Фев 2010

Что то к 3ей странице уже пошли теже ответы что были и на 1ой.
Господа нужно придумать что то новое иначе топик обречен... =)

Fortop · 16 Фев 2010

которые несостыкуются, да.

Я вот этого не понимаю. Ну не нравятся вам девочки(процедуры), ну чего Вы к ним лезете? Общайтесь только с мальчиками (объектами) и все у Вас будет стыковаться.

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

Я показал вполне конкретные примеры, демонстрирующие, что отсутствие в языке объектов базовых типов данных приводит, по меньшей мере, к уродливому написанию синтаксиса

Еще раз и по тому же месту. Вы привели примеры демонстрирующие Ваше неумение использовать ООП возможности языка. Именно отсюда ростут ноги в смешении типов и подходов.
Есть скалярные типы? Ну и отлично. Хотите объекты? Так используйте именно объекты, а не скалярные типы.
В чем сложность? Чем Вам мешают стандартные типы? Своим наличием?

Вот разумная мысль

fixxxer
Гибрид с проблемами роста, причем гибрид довольно неаккуратный и логически незавершенный.

Но жить с этим можно.

А у Вас крайне неконструктивный подход.

ммм... а что я должен был сделать?

Форк языка и делайте свой лунапарк. Слабо?
Ну если "слабо", то начните с малого - используйте только ООП возможности языка, не смешивайте одно с другим.

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

Глупости. Эта потребность является доказательством того, что люди разные, но не более.
Важно просто понимать области применимости "лапши", процедурного кода и ООП.
Поиметь автомобиль со скоростью болидов Ф1, с грузоподъемностью грузовиков, с комфортабельностью лимузинов и с энергопотреблением микролитражек - нереально.

Это надо таки понять.
Рекомендую отказаться от пытаюсь и занятся решением стоящего перед Вами вопроса.

P.S. Если бы Вы имели опыт работы с проектами живущими годами, то имели бы представление о количестве и качестве legacy кода в мире. Это объективная реальность и изначальность тут совсем не причем. Причина всегда! в человеке. Есть некий предел сложности систем для понимания каждого отдельно взятого человека.
Пытаясь, предусмотреть и реализовать все, Вы добъетесь только одного - мир никогда не увидит Ваш продукт.

P.P.S. И, да, если бы у Вас было желание решить вопрос, то топик был бы несколько о другом. Не обсуждение как все плохо и мешает Вам танцевать, а обсуждение путей решения.

топик обречен... =)

топик изначально был обречен самой формулировкой вопроса.

Beavis · 16 Фев 2010

Автор оригинала: triumvirat
эта потребность и есть прямое доказательство той изначальной корявости языка. Что я и пытаюсь доказать.

да, язык местами корявый... ты просто хочешь донести это до остальных?)
так и напиши - пхп говно, я разочарован)

dimagolov · 16 Фев 2010

"не нравится отечественный автором - сделай лучше"

это был бы офтопик, если бы не являлось прямой аналогией данной теме.

как и пхп, отечественный автопром это результат исторического процесса развития, со своими особенностями и недостатками. и если те же мотористы BMW на протяжении 4-х поколений вылизывают свои моторы что котячи яйца для получения максимальной мощности на единицу объема, то это не значит, что идентичного результата могут добиться мотористы того же ГАЗ-а, перед которыми ставились совсем другие задачи и которые разрабатывали моторы для сосем других условий производства и эксплуатации.

с пхп то же самое. обратная совместимость это очень сложная задача, отнимающая массу сил и времени и ограничивающая рост, но отказаться от нее не всегда возможно. собственно ООП подход и паттерны проектирования появились из желания получить обратную совместимость при разработке более естественными методами, чем это было до этого.

cDLEON · 16 Фев 2010

Мне вот интересно, все кто называет пых-пых недоязыком, тоже не могут придумать задачи, которую можно выполнять с помощью данных методов? Автор ни когда не реализовывал коллекции? С доступными для данной колекции методами. Которые будут удобно показываться автокомплитом....?
А, я же забыл, автор не признаёт ни каких IDE, кроме непонятно чем пахнущей байды, которую использует. И про которую я, например, даже и не слышал....

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

А вот это вообще казус... Автор использует ArrayObject ТОЛЬКО для того, что бы придать массиву объектное представление.
Автор - мой тебе совет... Используй это:

PHP:

$arr=Array('blablabla'=>'123','blablabla2'=>'234');
var_dump((object)$arr);

korchasa · 16 Фев 2010

triumvirat

$object->my_array;

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

В данном случае, с точки зрения пользователя, ты обращаешься к свойству объекта. Все остальное ему не ведомо. Поэтому $object->append('new_val') не имеет смысла. Вместо него должно быть array_push($object->my_array, 'new_val').

С $object->foo()['key'] согласен.

После питона как-то сильно не хватает всей его магии. Она очень помогает в кастомных коллекциях, например.

Тем, кто хочет написать, что магия - зло и неявное поведение, не стоит. Единственный стандарт на коллекции объектов и кортежи, в РНР, это массив. И другой появится не скоро. А без стандарта придется извращаться на передаче между модулями и библиотеками.

cDLEON · 16 Фев 2010

Не ну это вообще жесть... Просто фигею с этого топика...
Это тоже самое, что писать на СИ и возмущаться ПОЧЕМУ:

Код:

char *str;

Не выделяет память для САМОЙ строки...

korchasa · 16 Фев 2010

Автор использует ArrayObject ТОЛЬКО для того, что бы придать массиву объектное представление.

Я об этом же. ArrayAccess для обратной задачи.

Духовность™ · 16 Фев 2010

Автор использует ArrayObject ТОЛЬКО для того, что бы придать массиву объектное представление.

Ну ГДЕ это написано, что автор ТОЛЬКО это делает? Почему у вас манера писать о том, о чем вам не известно?

И потом, что плохого в том, что бы придать массиву объектное представление? Дополнить это представление необходимыми методами для удобства работы?

Автор ни когда не реализовывал коллекции?

Что ты вкладываешь в понятие коллекция?

-~{}~ 16.02.10 18:02:

Автор - мой тебе совет... Используй это:

$arr=Array('blablabla'=>'123','blablabla2'=>'234');
var_dump((object)$arr);

вообще не в тему. это не объектное представление массива, это просто объект с какими-то данными.

cDLEON · 16 Фев 2010

Ну ГДЕ это написано, что автор ТОЛЬКО это делает? Почему у вас манера писать о том, о чем вам не известно?

Вы меня, конечно, извините, но после слов вроде:

вообще не в тему. это не объектное представление массива, это просто объект с какими-то данными.

Какие ещё мысли могут прийти в мою больную голову?
--------
Какие цели вы приследуете, когда делаете массив объектом?
Где вот здесь:

PHP:

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

Удобство работы? У вас автокомплит на ключи массива появится? Или что? Я не понимаю!
Почему нельзя написать $cvar->my_array['key']['subkey'] ?
Почему нужно совать объекты даже туда, где это не оправдано?
Почему возможность сделать

PHP:

$config=$cvar->load('asd');
$config['asd']['asdasd']='asd';
$config['blabla']='blabla';
$config->save('asd');

Кажется вам не наглядной? И, самое главное, нахрена здесь $config->asd->key ? Что поменяется? Вам станет удобнее? А мне и так удобно. И самое главное - ни мной, ни процессором не делается лишних телодвижений. Вроде создания ещё одного объекта по-стандарту там, где мне это нафиг не нужно! А нужно будет - конструкция позволяет добавить такое поведение.
А вот у вас наверняка весь сыр-бор возник из-за того, что вы переООПешились, так и не поняв самого смысла ООП(и всё это дело у вас начало тормозить). И вините в этом не свои руки, а сам язык. Как говорится: плохому танцору....

whirlwind · 16 Фев 2010

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

Насчет публичных свойств тут уже неоднократно обсасывалось почему это не очень хорошо для ооп. Помимо того, благодаря особеностям php, лично я не вижу разницы между $config['asdasdasd'] и $config->asdasdasd. Оба эти варианта - плохие.

Духовность™ · 16 Фев 2010

Насчет публичных свойств

а кто говорит о публичных свойствах?

cDLEON

Какие цели вы приследуете, когда делаете массив объектом?

помимо реализации методов для работы с объектом-хранилищем и специфическими деталями, как я уже сказал выше, пытался таким образом подвести свой костыль под синтаксис PHP. Об этом собственно и топик.

Мне не в кайф было писать такие вещи:

PHP:

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

ОЧЕНЬ напрягало отсутствие подобного шаманства:

PHP:

$object->foo()['key']['subkey']; // error

мне нужно было до предела упростить получение значения

PHP:

//  ArrayObject   
if ($this->request->getRequest()->offsetExists('id') && $id = $this->request->getRequest()->offsetGet('id'))

вместо:

PHP:

// my cover 
if ($id = $this->request->getRequest()->id)

А имитировать объект массивом - я считаю не правильным. Синтаксис языка должен быть прозрачен. Но это моя точка зрения и я, возможно, её поменяю в виду того, что именно таким путем пошли разработчики языка и мне деваться некуда.

whirlwind · 16 Фев 2010

triumvirat cDLEON говорит о том, что не видит разницы.

C_TIGER · 16 Фев 2010

triumvirat
топик об обсасывании пальца собственной неувязчивости. о чём уже многие сказали

AmdY · 16 Фев 2010

PHP:

А имитировать объект массивом - я считаю не правильным.

чёрт, знаю почему у меня последние дни мучает бессоница, это потомузнаю, что php переменные на самом деле zval, а то и вовсе нолики и единички. а ведь и дед мороз оказался вымышленным.

ArrayObject больше для того, чтобы с _объектом_ можно было работать как с массивом и использовать функции для работы с массивами count foreach ...... а не "имитировать объект массивом"

нахрена здесь $config->asd->key

это имет смысл для избавления проверак типо isset, $this->getRequest()->user_id->toInt(); $this->getRequest()->user->id->toInt();
если нет user_id или user, можно вернуть объект затычку, котораяed итоге вернёт 0 и без нотисов.

C_TIGER · 16 Фев 2010

AmdY
вапще еррор репортинг 0 и всё =)

PHP:

<?/*
error_reporting(E_WARNING | E_ERROR);
$time=microtime(1);
for($i=0;$i<100000;$i++){ if($var['key']){}}

print "TName: no Nocite; Time = ".(microtime(1)-$time)."\r\n";
*/


error_reporting(E_ALL);
$time=microtime(1);
for($i=0;$i<100000;$i++){ if(@$var['key']){}}

print "TName: with Nocite; Time = ".(microtime(1)-$time)."\r\n";

/*
TName: with Nocite; Time = 0.219910860062
TName: with Nocite; Time = 0.208234786987
TName: with Nocite; Time = 0.205691099167
TName: with Nocite; Time = 0.204789876938
TName: with Nocite; Time = 0.217062950134
TName: no Nocite; Time = 0.111096143723
TName: no Nocite; Time = 0.108511209488
TName: no Nocite; Time = 0.10800909996
TName: no Nocite; Time = 0.111192941666
TName: no Nocite; Time = 0.109051942825
TName: no Nocite; Time = 0.118571043015
*/
?>

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

Новичок

Продвинутый новичок

Новичок

Продвинутый новичок

Новичок

Новичок

Banned

Новичок

Онанист РНРСlub

LIMB infected

Онанист РНРСlub

LIMB infected

Продвинутый новичок

Онанист РНРСlub

TDD infected, paranoid

Продвинутый новичок

TDD infected, paranoid

Новичок

Пью пиво

Новичок