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



Вот про это я говорил.

Интересно, а в разделах по JavaScript-у, наверное, рассказывают про "мощь" прототипного программирования, в lisp про "мощь" функционального, а в С про "мощь" процедурного?  

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

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


Правильнее будет сказать:
1. PHP изначально не являлся ОО языком.
2. На данный момент в PHP ООП реализован в не достаточной степени.


Это применимо и к PHP, только в отличии от VB это происходит в несколько этапов и  нету таких четких границ.


Будет в PHP 5.3 http://wiki.php.net/todo/php53



Вы правы. В PHP все не приватные методы по сути являются виртуальными. Т.ч. полиморфизм реализуется в полное мере.

Определяете функцию B protected и вызываться будет именно дочерняя функция.


Хе хе. Любые конструкции в высокоуровневых языках - это и есть по сути, как вы сказали "синтаксически стилизованный набор функций"   


А как они "живут", как набор инструкций может быть?   


Тут совершенно согласен. А название темы вообще странное...


Тут ноги растут из типизированости в PHP (точнее ее отсутствие).
Ведь что такое событийность? Событийность это всего-лишь массив делегатов, и не более того!

Делегаты в PHP есть? Есть - это тоже самое что и строка. Ну напишите перед ней /* @var Delegate $delegate */ вот вам и делегат.
Асоциативные массивы в PHP? Можно не отвечать.
Подписка/отписка на/от события = добавление/удаление делегата в/из массив.
Вызов события = поочередный вызов делегатов массива.
Все! Вот вам и событийность и не нужны никакие __call.

А если еще учесть, что в PHP 5.3:

То можно использовать событийность практически так же как в C#

Возьмите кнопочку... Тут уже благодаря системным вызовам и прерываниям - не просто синтаксически стиллизованный код. Но по сути, конечно, есть такая тема. Другое дело, что в ПХП это именно стилизованный синтаксис 100%.


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


Типизация тут не при чем. Событийность - реакции на определенные сигналы, поступающие от туда или отсюда. Делегаты - термин по крайней мере не из С++, хотя может и из МФЦ, но я с ним не работал. И потом, Делегат - функция (если я ничего не путаю), т.е. более высокий уровень абстракции.


Хорошо, есть объект А и Б, с методом А1 и Б1. При срабатыавании Б1 должен автоматически вызваться А1. Б о А ничего не знает. Также, как и А о Б.


Ничего не могу сказать на эту тему, не смотрел еще этих вещей...

Круто, не знал...   

Ага, всего что не хватает щас в PHP5.X будет в PHP5.3

Это сообщение отредактировал(а) lukas - 25.8.2008, 21:25

По поводу кнопочек, специфика HTTP протокола такая, что события типа onClick в server-side скрипте просто не уместны в данном контексте, т.к. они происходят на стороне клиента.
Возьмем, к примеру, ASP.NET. В C# ведь используется событийность? Однако что происходит при создании события onClick на кнопку? - Генерируется куча джаваскрипта и куча кода в на C# - вот тебе и вся событийность... по сути всего-лишь фитча IDE. Так чем же PHP в этом плане хуже? 


Т.е. по твоему, если объект абстрагирован от системных вызовов - то это уже в понимании ООП и не объект вовсе? В таком случае C# так же не ОО язык, т.к. тоже не работает непосредственно с системными вызовами.


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


А что такое реакция на сигнал? Это вызов определенной функции при изменении состояния некоторого объекта. 


Почти. Делегат - это указатель на функцию. Насколько я понимаю, в C++ это так и называется?


Как это не знает? А сначала должен подписать на событие А1, прежде чем Б сможет его автоматически вызвать. Т.е. по сути передать А должен передать делегат функции A1 объекту Б. Тогда при срабатывании Б1 просто будут вызваны все делегаты которые ранее были переданы объекту.

sTa1kEr, давай сиходить из того, событийность должна реализовываться не программистом, а языком.  
В ПХП этого нет. Вот я о чем. Реализовать событийность самому - можно, а вот сделать что-то вроде:
connect(A, A1(), B, B1()) - нельзя. На счет 5.3 я не говорю - не знаю. Т.е. объекты А и Б не знают о сущестовании друг друга, об этом знает программа, которая связывает сигнал со слотом.


Типизация и событийность - совершенно разные вещи, они тут не при чем (в совокупности).


Так вот и покажите мне в ПХП - объект, который будет себя вести КАК кнопочка. Т.е. его событийность будет реализована средствами ПХП, а не программиста (реализация самих событий - конечно за программистом).


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

Такого объекта нет ни в PHP, ни в одном другом server-side языке, т.к. такое не возможно. В качестве наглядного примера я выше привел ASP.NET - там все тоже самое, с одной разницей, реализацией события занимается не программист, а IDE. В принципе Zend может сделать тоже самое и для PHP.


Хорошо, в таком случае весь вопрос в том, что в PHP нет такой конструкции event (по сути просто пары встроенных классов)? Да этого в PHP нет и хоть это не сложно реализовать в PHP, скорее всего этого не будет до тех пор, пока в этом нет надобности (а особой надобности в этом, имхо, не будет пока нет полноценной многопоточности). Однако это не мешает использовать событийность и ОО подход.

Ну дык и я про тоже. Такова специфика ПХП...
Среда это среда. А я говорю, ну как бы про транслятор чтоли, в совокупностью с системой. Сейчас могу не корректно выражать мысли, ибо голова забита несколько другими вопросами.


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


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


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

Многопоточность тут тоже не при чем. В ПХП это не так актуально, а если надо, есть средства ее реализовать руками. А сигнал/слот может и в одном потоке работать.


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

Это сообщение отредактировал(а) Mal Hack - 25.8.2008, 23:34

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


Это специфика не PHP, а HTTP протокола.


Еще как причем. Если в крации, то реализовать ОО модель в PHP на уровне .NET-а мешают, на мой взгляд, именно эти две вещи: многопоточность, не строгая типизация.

Mal Hack, PHP это высокоуровневый язык, ты же рассуждаешь с позиции низкоуровнего C++.

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


Давай так. Отбросим кнопочки. Мы про событийность внутри самого ПХП, т.е. в скрипте. Тут HTTPне при чем. Тут специфика структурного, интерпретируемого языка программирования, как Perl, например.


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

Зачем тут многопоточность? есть сигнал - выполнилась функция, по другому:

Да, для Визуалки испольузется многопоточность, но по сути, сам механизм сигнал/слот не обязательно должен быть в другом потоке.


А при чем тут типизация? То, что это минус ПХП и т.д. - отложим, не в этом суть темы, чем  она мешает событийности? Скажем так, да жесткая типизация позволилабы прописывать объекты и т.п. в этом ты имеешь ввиду?


Ну что такое низкий и высокий уровень я бы еще поспорил. Это условность всетаки. И потом, В C++ той событийности, о которой я говорю нет, ее дает Qt, например. Это уже более высокий уровень, все-таки.

По тем причинам, что в этом практически нет потребности. Для кнопок этого не сделать, а отсутствие многопоточности не позволит создать сколько-нибудь приемлемое серверное приложение. Остаются только простейшие события вроде onRowDeleted, onPageRender итд - это просто реализуется и как-то не в стиле PHP что-ли... В общем не стоит овчинка выделки на данные момент, то что вместо /* @var event */ можно будет написать просто event, кроме большей наглядности ничего не даст. Разве что "для галочки" реализовать.


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

Наглядный пример http://php.net/socket-select - вот как приходится извращатся, что бы избежать fork-ов! И это еще цветочки! Естественно, про реализацию event patern-а я вообще молчу... 

Строгая типизация естественно тоже сама по себе ни причем. Но она во первых - так же сковывает развитие PHP (тут можно долго перечислять проблемы из-за отсутствия типизации, но это уже к оффтоп). Во вторых - она (точнее ее отсутствие) вводит в заблуждение, раз в PHP нету типа Delegete - значит в PHP нету делегатов, анонимных делегатов... раз нету ключевого слова event, значит нельзя использовать событийность, и все в таком духе. Хотя на самом деле все это есть, пусть и называется строкой... Будь строгая типизация - ничего бы такого не было.
Кстати, еще пример - SplTypes. Eще больше двух лет назад был уже реализован тип Enum (это из C#) + реализованы попытки совместить строгую и не строгую типизацию... И ведь даже работает, только вот не нужно никому.



Я не знаю что это за функция, но насколько я предполагаю это и есть подписка на событие? И в чем проблема тоже самое сделать в PHP?
Опять же пример из C#, взять подписку на событие и пройтись рефлектором. И что мы увидим? Да всеголишь вызов метода add_Listener() у обычного, ничем не отличающегося от других класса Event ! Т.е. по сути событие это класс в из 3 методов (addListener, removeListener и fire) и одного свойства - коллекции делегатов (читай массив указателей на функции). 

Твой пример портированный на C#


А вот как бы это могло выглядеть в PHP


А вот как это уже сейчас можно использовать


Найди 3 отличия   

Это сообщение отредактировал(а) sTa1kEr - 26.8.2008, 14:46

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


Mal Hack, ты думаешь во всех языках под ОС релизовано событийность, да событийность часто реализуется только за счет IDE, и за частую события это обычные свойства с read и write (которые принимают в качестве результата ссылку на функцию)... Далее же где вызывать то или иное событие определяется часто программистом...

События довольно легко реализовать через callback функции, и они не имеют никакого отношения к ООП. 

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

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

Согласен.


Согласен, в какой-то степени, но в концепте тоже.


Ну, в принципе да.


Да, но, согласись, это криво, по сути это callback, не очень удобный.
В принципе да, это механизм, несколько не тот, который я считаю оптимальным, но реальный, работающий механизм.
С какого момента это стало возможно?
Плюс в репу.


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


Потому, что вопрос коснулся конкретной реализации задачи построения событийности.


В данном случае ООП - проектирование - исключительно...

ну если нет в ПХП событийности, что отказываться от использования классов???

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

Это сообщение отредактировал(а) lukas - 27.8.2008, 07:34