Forth
http://www.fforum.winglion.ru/

Форт и ООП
http://www.fforum.winglion.ru/viewtopic.php?f=25&t=2050		 Страница 2 из 6
Автор:  вопрос [ Вт апр 07, 2009 20:59 ]
Заголовок сообщения: 
Цитата:
Ведь от ООПа на самом деле не все и не всегда нужно.
Не всегда, но долгоиграющий проект лучше делать с ООП - сильно организует
Автор:  Wlad [ Вт апр 07, 2009 23:04 ]
Заголовок сообщения: 
Согласен.
Например, в обсуждаемом нами Инферно-Лимбо, применен приём (как я называю) "выбор типа по месту".
Если в функцию (метод) передаётся некий объект, то мы можем затребовать у этого объекта наличие метода данной сигнатуры.
И тогда не нужны чисто "антуражно-украшательские" танцы с бубнами по описанию интерфейсов-классов.
Очень удобно.
Напрмер мы имеем некую обобщённую функцию, в которой описан вызов методов (именно с такой сигнатурой), про которые мы думаем, что они именно такую функциональность и обеспечивают. И не заморачиваемся типами и классами даже ещё не созданных (и не спроектированных!) классов и типов. Более того, собственно ничего формального (обусловленного в языке правилами описания "классов-типов") делать-то и не надо! Просто вводим в объект функцию нужного вида и наполняем её неким кодом.

А всякия там синтаксически-мазохистические изыски оставляем дяде Бьярну со товарисчи.
Автор:  garbler [ Ср апр 08, 2009 09:57 ]
Заголовок сообщения: 
Wlad писал(а):
в обсуждаемом нами Инферно-Лимбо, применен приём (как я называю) "выбор типа по месту".

у этого есть общепринятое название - "duck typing" - свои недостатки тоже есть http://www.xoltar.org/old_site/misc/static_typing_eckel.html, подход, кстати, не уникален, используется многими языками и в чём-то перекликается со "structural subtyping".

в любом случае, этот подход не является взаимоисключающим к тому, что принято называть ООП.
Автор:  mOleg [ Ср апр 08, 2009 11:06 ]
Заголовок сообщения: 
пардон, выделил обсуждениее Форт и ООП в отдельную тему для удобства.
Автор:  mOleg [ Ср апр 08, 2009 11:09 ]
Заголовок сообщения: 
вот интересно, в какой последовательности вы определите свойства ООПа с точки зрения важности\частоты применимости?
вот по-моему скромному мнению, главное самое - это управление пространством имен, а остальное второстепенно и как бы в нагрузку идет.
Автор:  garbler [ Ср апр 08, 2009 13:26 ]
Заголовок сообщения: 
Wlad писал(а):
А ЧТО ПРИНЯТО НАЗЫВАТь ООП ? Опять скатимся на ....

Необязательно, всё уже сказано http://www.helloworld.ru/texts/comp/other/oop/ch02.htm
особенно интересно сравнить с первым изданием (это там, где был common lisp, smalltalk, object pascal, ada и куча других экзотических систем).

mOleg писал(а):
вот интересно, в какой последовательности вы определите свойства ООПа с точки зрения важности\частоты применимости?

в книгах за последние 10-15 лет точка зрения плавно смещается от encapsulation, inheritance, polymorphism к abstraction, encapsulation, modularity, hierarchy.

а что касается моего мнения - я бы не выделял, чем больше можно использовать в процессе написания (и при этом контролировать получающийся код) - тем лучше.
Автор:  mOleg [ Ср апр 08, 2009 14:36 ]
Заголовок сообщения: 
garbler писал(а):
а что касается моего мнения - я бы не выделял, чем больше можно использовать в процессе написания (и при этом контролировать получающийся код) - тем лучше.

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

Все-таки наше все - это ПРЕОБРАЗОВАНИЕ ПОТОКА ДАННЫХ, или как там у Броуди написано?
ООП в Форте лишняя и самое главное - это чужеродный набор абстракций/понятий (имхо, конечно),
а главное есть собственный набор средств и методик, позволяющих делать то же.
к тому же, когда говорят про ООП, сразу возникает необходимость/проблема типизации...

Мне кажется, что разговоры про ООП в Форте чаще всего возникают из незнания/непонимания идеалогии Форта и собственно самого языка.
Автор:  K`[f [ Ср апр 08, 2009 20:23 ]
Заголовок сообщения: 
mOleg писал(а):
Мне кажется, что разговоры про ООП в Форте чаще всего возникают из незнания/непонимания идеалогии Форта и собственно самого языка.


ООП есть способ структурирования нашего представления предметной области. Обеспечивает, конечно, некоторый оверхед, но это цена за гораздо большую гибкость. В чём противоречие со средствами Форта - мне не ясно, например.
Автор:  Wlad [ Ср апр 08, 2009 20:52 ]
Заголовок сообщения: 
А в чём гибкость?
Автор:  K`[f [ Чт апр 09, 2009 07:15 ]
Заголовок сообщения: 
Wlad писал(а):
А в чём гибкость?


Гораздо меньшая связность между компонентами. Это надо самому попробовать, чтобы понять. Особенно полезная штука - полиморфизм. Чем-то напоминает обычные операторы +/-* в каком-нибудь Си - их тоже можно произвольно применять к аргументам, которые это допускают. Только уровень, в общем, другой - даже в Форте это будет оправдано.
Автор:  K`[f [ Чт апр 09, 2009 07:24 ]
Заголовок сообщения: 
Вообще, на это можно взглянуть несколько по другому. Мы не можем <u>эффективно</u> сделать операцию +, работающую с произвольным типом данных (в разумных пределах, конечно). Просто в силу природы Форта - это обратная сторона его расширяемости. Поэтому у нас и есть набор D+ F+ и т.п. Там, где обычный компилятор заранее знает аргументы, которые будут, мы можем лишь потребовать их. Т.е. для "+" - чтобы было две ячейки на стеке. Опять же, возвращаясь к давнему спору, именно поэтому я сторонник раздельных стеков для адресов. Ну а в классических скриптовых языках эта проблема решается сами знаете как... оверхед жуткий.
Но вот в случае с манипуляцией объектами нам ничто не мешает использовать полиморфизм, т.к. на нижнем-то уровне это всегда будет работа с адресами - т.е. зоопарка из <u>физически</u> разных типов тут нет! Поэтому, имхо, некоторый <u>стандартный</u> ООП в Форте иметь дюже желательно. Да и вообще стандартную библиотеку следовало бы развить.
Конечно, оффтопик, но я хотел бы видеть примерно следующее:
1.ООП
2.Стандартный GUI (примитивный, но достаточный для мелких задач)
3.Работу с потоками
4.Строки - СТАНДАРТНЫЕ (с этим есть сейчас некоторые проблемы, да, что именно делать)
Ну и т.д. Но это, опять же, не для микроконтроллеров задачи решать... :)
Автор:  VoidVolker [ Чт апр 09, 2009 08:08 ]
Заголовок сообщения: 
K`[f писал(а):
4.Строки - СТАНДАРТНЫЕ (с этим есть сейчас некоторые проблемы, да, что именно делать)

Я постоянно в ннкроне работаю со строками и соответственно есть опыт и наработки, так что могу поделиться 8)
Автор:  Wlad [ Чт апр 09, 2009 17:12 ]
Заголовок сообщения: 
K`[f писал(а):
Wlad писал(а):
А в чём гибкость?


Гораздо меньшая связность между компонентами. Это надо самому попробовать, чтобы понять. Особенно полезная штука - полиморфизм. Чем-то напоминает обычные операторы +/-* в каком-нибудь Си - их тоже можно произвольно применять к аргументам, которые это допускают. Только уровень, в общем, другой - даже в Форте это будет оправдано.


Понятно.
Позвольте поинтересоваться, Лёха, а Вам, извините, годкофф-то скольки?
Никакого наезду!
Всё - касательно перечисленных Вами "гибкостей"! И - "надо самому попробовать, чтобы понять". Просто, видите ли, СТОЛЬКО, не то, что "пробовал", а прям-таки изваял систем, что - "имею право"... :D Я, извините, уже просто ДЫШУ ООП. Лет 17. И, в отличие от восторженных юношей, которые только-только начинают входить в серьёзную программерскую и проектную жизнь, мне уже не всё (ДАЛЕКО НЕ ВСЁ!!!) в таком розовом свете видится и зрится. ОСОБЕННО - на счёт "меньшей связности между компонентами"...
Автор:  mOleg [ Чт апр 09, 2009 18:51 ]
Заголовок сообщения: 
K`[f писал(а):
Гораздо меньшая связность между компонентами. Это надо самому попробовать, чтобы понять. Особенно полезная штука - полиморфизм. Чем-то напоминает обычные операторы +/-* в каком-нибудь Си - их тоже можно произвольно применять к аргументам, которые это допускают. Только уровень, в общем, другой - даже в Форте это будет оправдано.


вот недавно приводил пример для человека, повторюсь:
util/ utit.fts

Unit: Двигай

Sub Unit: Рукой
F: Вперед ... ;F
F: Назад ... ;F
EndUnit

Sub Unit: Ногой
F: Вперед ... ;F
F: Назад ... ;F
EndUnit
EndUnit

И пример использования:
... Двигай Рукой Вперед Двигай Ногой Назад ...


похоже?
Автор:  mOleg [ Чт апр 09, 2009 18:57 ]
Заголовок сообщения: 
K`[f писал(а):
Опять же, возвращаясь к давнему спору, именно поэтому я сторонник раздельных стеков для адресов.

я вас понимаю, и думаю о том же, но есть ряд неприятностей тут:
1) код становится не совместим
2) может не хватить регистров для указателя стека (на ix86 это проблема)
3) увеличение количества слов

K`[f писал(а):
3.Работу с потоками

что под этим имеется ввиду? в смысле что не так с потоками в том же СПФ, например?

K`[f писал(а):
4.Строки - СТАНДАРТНЫЕ (с этим есть сейчас некоторые проблемы, да, что именно делать)

Какие проблемы по-вашему?

P.S.
почему-то как только к Форту приходит человек с маинстрим языка, сразу пытается писать ООП собственный...
а старые Фортеры ООП как-то не слишком пользуют в Форте
Страница 2 из 6 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/