Я же написал, что я прочитал первые 3-4 страницы топика, больше не выдержил.
Да и у меня сложен так ум, что проще понять примерами, чем теорией.
А вообще сложно назвать ваше обсуждение теорией. Уже обсуждение в стиле:
"Начали про то, как установить унитаз, заканчиваете о том, как сделать ремонт во всём туалете." 
P.S: Ничего личного.
P.S2: Остаюсь скромным наблюдателем
 

Это сообщение отредактировал(а) Oflashp - 3.8.2007, 12:28

Я точно также, но есть некоторые теоретические аспекты, которые надо понять, как теорию..


В догонку. Не знаю как и что в Питоне реализовано, но надо отдавать себе отчет, что сегодня, фактически используются 2 модели ООП.
Первая - чисто ООПшная модель - используемая в визуальном программировании, где присутствует принцип событийности, немаловажный для ООП, как вид взаимодействия объектов.
Вторая - информационная, как в ПХП, например, где объект в коде программы не отождествляется с каким-то вещественным субъектом, кнопкой и т.п., т.е. носит, фактически, информационный, сугубо механико-рабочий характер. 
Питон, если я не путаю, из того, что я о нем слышал, относится к первой категории.

ну я бы не стал так разделять. В конце концов, что мешает мне реализовать событийную ситему в php. Ничего. Поэтому это  не модели, а лишь способ применения. И зависит от решаемой задачи.

Да, разделение - условное. Нов от в PHP вы не можете использовать событийность, связанную с графисечким интерфейсом - раз. Два, любоую событийность, как взаимодействие между объектами, вы должны, в случае PHP, полностью отпрограммировать сами, а в том, первом случае, о чем я писал выше, механизм событий, реализовывается через системное API.

Mal Hack, 
Можем мы использовать событийность, связанную с графическим интерфейсом. AJAX нам на что?
Если не хочется программировать событийную модель самостоятельно - можно всегда использовать фреймворк... благо они есть.

Допустим событийная система реализована в биндингах GUI библиотек для в php, в частности в PHP-GTK. А именно системное API конечно есть, но не так уж и частно встречается, сразу на ум приходит Delphi. Так что я не совем соглашусь, что имеено это делит ООП на модели.

AJAX - JavaScript, который мы моем лишь связать с PHP. Точнее PHP использует не своё средство представления событийности

Присоединюсь к чату 

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


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

Событийность имеется ввиду во время работы скрипта, а тот же Ajax просто вызывает скрипт PHP по какому-то действию, а вот внутри PHP событийности нет.


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


Без класса нет объекта!!!
JS либо должна в себе содержать внутри определения классов, либо она просто дает синтаксис, близкий к ООП...

А вот и есть 
Синтаксис она как раз дает далекий от "классического" ООП. Но в том чтобы следовать принципам ООП это ей не мешает.

JavaScript я привел как пример концепции прототипного наследования, к тому же в этой концепции нет классов.
Ada95 - пример реализации концепции статической типизации (по умолчанию запрещено наследование).


Потрудитесь почитать собственную ссылку 10 строками ниже и увидите: "...объекты являются экземплярами некоторого заранее описанного класса (однако например в таком языке как JavaScript понятие класс не используется вовсе)..."

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


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


Пожалуйста, не давите меня такими сильными аргументами как "бред" и "яйца без курицы не бывает". В JS объект может определяться во время создания. Причем его как вы выражаетесь "опеределение" может изменяться по ходу выполнения программы. Где здесь бред? Где "система в программе заранее создает объект по своим прототипам"? Давайте не будем опускать довольно мощный язык (и представляемую им концепцию) до уровна onclick="" и getElementById, только потому, что в основном он исп-ся в браузерах.


Событийность таки есть, взять хотя бы сокеты, можно их слушать, можно реагировать на изменение их состояния. 


ООП - это три принципа (наслед-е, инкапсуляция, полиморфизм), надеюсь с этим никто спорить не станет. Все эти 3 принципа реализованы в JS, есть и объекты, но при этом нет классов. Что вы имеете в виду под словами "должна в себе содержать внутри определения классов"? Нет в JS классов ни внутри, ни снаружи, и не нужны они там. Либо у нас с вами разные определения слова "класс"...

Определение этого класса, так или иначе, должно быть, оно зашито в движок JS.
В противном случае это структура с синтаксисом объектного доступа + изменяемость.


Эта событийность реализуется ручками, от и до...


Я уже писал выше... Удосужтесь еще раз почитать... С точки зрения практической реализации ООП вы правы, но по большому счету - нет.


Если вы работали в Делфи, то я имею ввиду TObject, определенный в самом языке, а не тот, который определяете вы.

Приведи пример, где не ручками.

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

"Класс", это наследие жесткой типизации, что есть ограничение компилирующих языков (хотя многие скажут, что это благо, а не ограничение). В C++ нужна эта иерархия, чтобы на этапе компиляции преобразовать вызовы функций в переходы на нужный участок памяти. А в PHP уже и не нужно, там наследование классов, просто позволяет более легко строить эти классы. А если нужно вызвать какой-то метод объекта, то важно только само наличие этого метода у объекта, а не принадлежность его какому-то классу.

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

Класс определяет набор однотипных объектов. Однако, уже в PHP это не совсем так. Т.к. как там в начала цепочки поиска ставится сам объект. С учетом того, что в него можно добавлять свойства, а так же устроить перехват несуществующих методов, то все становится не так четко. Объект, в который добавлены новые свойства, уже не совсем объект того класса, от которого наследован, он не до конца подобен другим объектам того же класса.

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

Преимущества такого подхода (во всяком случае для области применения подобных языков, это преимущества):

- Можно создавать набор похожих, но несколько различных по поведению объектов, не создавая при этом громоздкую иерархию классов и не таская её вместе с программой (очень важно для JS)
- Можно динамически изменять (дополнять) поведение объектов определенного "типа" путем изменения прототипа (для JS с обилием предопределенных объектов и различными реализациями в браузерах, очень полезно)
- Можно динамически изменять иерархию наследования (конкретно в JS нельзя)
- Утиная типизация значительно повышает гибкость. Это не совсем к прототипам, но тоже то, чего нет в "классическом" ООП.

Т.о. "классы", отнюдь не такая необходимая вещь.

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