Предистория. Сказал я как-то что-то вроде "...объектная модель языка...". Меня заплевали. Но как надо говорить не сказали. Вопрос - а как же правильно формулировать свою мысль на человпеческом языке?

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

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

ЗЫ: Интересуют как русский, так и английский варианты.

объектно-ориентированные расширение языка
object-oriented extension to *

ящитаю

alexvs11, пожалуй так и надо. Единственное, существует вариант, который я в первом посте не описал. 

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

Определите понятие "объектно-ориентированный язык программирования". Иначе, дальнейший разговор лишён всякого смысла.


Я хочу это видеть! Это премия Тьюринга 100%. Никому такое не удавалось до сих пор. Все создавали новые языки, расширяя старые. А тут - раз и в дамки!


Это как раз когда создают новый ЯП на основе старого, так говорят. Скажем, Objective ML: An effective object-oriented extension to ML.


Как Вас понимать? В языке есть поддержка ООП? Определите тогда (опять таки) ООП. Затем, расскажите, насколько хорошо оно поддерживалось и каким образом эту поддержку удалось расширить за счёт этих Ваших мифических "модулей".

Это сообщение отредактировал(а) kemiisto - 16.4.2012, 23:19

О сколько нам открытий чудных
Готовит просвященья дух!

LabVIEW (NI, США) до версии 8.2 (2006 год), если не ошибаюсь с подверсией, не имел собственных ООП возможностей. Первая версия пакета GOOP (Endevo, Швеция), позволяющая создавать ОО решения средствами этого языка, вышла в 1996м (то-ли под LabVIEW 4, то-ли под 4.1 - не помню). Позже появились и другие пакеты для той же цели.


С версии 8.2 в язык введена собственная, весьма экзотическая модель. Экзотичность ее заключается в том, что объекты передаются не по ссылке, а по значению (т.е. самый основной принцип ООП не соблюдается). С другой стороны, поддерживаются такие базовые возможности ООП как инкапсуляция, наследование классов и полиморфизм.

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

Что это за принцип!?  Принцип "ООП - это так, как в Java" что-ли?

Экзотика обусловлена спецификой этой поделки. Там dataflow, а с такой моделью выгодна стратегия передачи по значению. Паралеллизм "искаропки". А если добавить возможность передачи по ссылке, то добро пожаловать Адъ и Израиль многопоточного программирования. Protected sections, mutexes, race conditions - всё там есть! 


Этого достаточно, исходя из попсового определения ООП. А ссылочные типы данных (и возможность передавать аргументы функций по ссылке) нужны, скажем, для упрощения построения рекурсивных структур данных. 


Посмотрел. Это можно назвать либо OO Framework (ОО каркас), либо ОО Toolkit (ОО инструментарий, ОО пакет). Я ратую за toolkit по-вражьи и инструментарий по-православному.  Каркасом лучше такое не обзывать.

kemiisto, честно говоря, мне скучно начинать холивар в терминах 


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

 Здесь с Вашим жаргоном я, пожалуй, соглашусь. Этого достаточно именно исходя из попсового определения. Но ведь существует и не-попсовое. Более того, даже и не-попсовые модели ООП, применяемые в разных языках, существенно разнятся по своим возможностям. Вспомните, например, С++ с множественным наследованием, Java с интерфейсами и VB6 с отсутствием какого бы то ни было наследования.


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

Так вот, мой вопрос чисто лингвистический: как назвать ту часть пакета, которая не toolkit, а набор решений. Всегда называл примененной моделью ООП (implemented OOP model),  но вот задумался - правильно ли называю.

Я бы лучше говорил просто о реализации (принципов) ООП (OOP implementation). Есть встроенная реализация (без ссылочных типов), есть сторянняя - с таковыми.

Пожалуй так будет грамотне всего. Но, не во всех случаях можно приментить без дополнительных разъяснений. Слово implementation используется в программировании так широко, что само по себе (без узкого контекста или дополнительных слов) информационную нагрузку несет слабую. Например, не скажешь:
Пакет включает набор инструментов и реализацию (The package includes toolkit and implementation).

Думаю может я зря зациклился на единственном значении. Может надо вместо слово модель использовать два, например, разных термина, в зависимости от ситуации?

Ты так говоришь, будто Common Lisp никогда не видел. Да и во многих других динамических языках ООП обычно реализуется просто как библиотека/модуль.

Это сообщение отредактировал(а) k0rvin - 10.6.2012, 17:09

k0rvin, Common Lisp - отдельный язык. На оф. сайте об этом написано чёрными буквами на белом фоне.


Вот так новость. Я ни одного такого языка не видел.

kemiisto, я, конечно, всех языков, но не думаю что задача такая уж сложная.

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

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

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

Эээ... в смысле? Что значит "отдельный" и к чему ты это? CLOS не вшита в ядро CL.


Например Scheme/Racket, TCL, Perl.

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

Добавлено через 1 минуту и 40 секунд

что именно за ооп такое в Scheme?

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


Не совсем понял вопроса. В Scheme нет искаробки синтаксиса для написания программ в ООП-стиле, но некоторые реализации предоставляют подобные расширения. Тот же Bigloo, емнип. Ну и никто не запрещает тебе самому реализовать простую объектную систему, благо это делается в сотне-две строк кода. (а в самом примитивном случае и 20 строк достаточно).