LINUX.ORG.RU

tcl/tk-lor-faq

 ,


2

5

Доброго времени суток дорогой LOR. Решил вот сделать небольшой FAQ по прекрасному на мой взгляд языку Tcl и его привязке Tk. Многие наверняка будут фыркать и говорить «Закопайте обратно» или «не нужен». Но давайте будем объективны - Tcl один из трех классических скриптовых языков (цитата с педивикии), который в отличии Perl и Python очень плохо освящен, а ведь у него есть такие преимущества как простота, быстрота разработки прикладных программ, возможность писать в функциональном стиле, хорошая реализация метапрограммирования. Ну и в конце-концов, это же «Lisp on Drugs!». Более или менее нормального FAQ в рунете не нашел.Поэтому предлагаю оформить его аналогично lisp-lor-faq.

Для начала ответим на некоторые самые простейшие вопросы:

Что такое Tcl?

Tcl - это скриптовый язык программирования высокого уровня. Считается одним из трех классических скриптовых языков. До пришествия РНР использовался вместо (если мне сейчас память не изменяет). Очень тесно взаимосвязан с тулкитом Tk, что позволяет в короткие сроки писать достаточно функциональные программы с GUI.

Зачем учить Tcl, ведь можно использовать любой скриптовый язык со связкой с Tk?

Можно. Но это не совсем торт=), лучше использовать любой тулкит в «родной» для него среде. Да и программы на чистом Tcl/Tk работают быстрее, чем при «костылестроении» с Ruby/Tk, Perl/Tk и пр., так как тащат за собой обе среды исполнения. Да и зачем иметь установленные два интерпритатора? Проще работать с одним (удобнее, да и с переносимостью проще).

Но есть же Lisp!

Есть. И Тикль с ним некоторые программисты сравнивают. Даже называют «Tcl - Lisp On Drugs». Языки и правда похожи - работа со списками, метапрограммирование. Но есть и серьезные различие. Так в Тикле все есть строка, а не символ.

Могу ли я писать на «Тикле» Функционально?

Можете. Tcl позволяет писать в функциональном стиле.

Какие парадигмы поддерживает Tcl/Tk?

Императивную, функциональную, объектно-ориентированную.

Ладно, уговорили, с чего начать?

Ну для начала можно ознакомиться со статьей в Вики (http://ru.wikipedia.org/wiki/Tcl), потом перейти к самому простому туториалу на русском (http://tclstudy.narod.ru/)

Какие есть реализации Tcl/Tk?

Как таковой Так-тикль один, его разработку сегодня ведет Tcl Core Team, но существуют так же расширения для него: стандартная реализация Tcl (http://www.tcl.tk/), экзотикль (XOTcl: http://media.wu-wien.ac.at/, расширение для ООП), iTcl (Первое ООП расширение, Inct Tcl, на нем написана iWidgets: http://incrtcl.sourceforge.net/), SNIT (объектный клей для Tcl, включен в стандартную библиотеку Tcl, оф.документация: http://www.wjduquette.com/snit/snit.html), STOOOP (ООП-расширение написанное на Tcl, так же сегодня входит в стандартную библиотеку, оф.документация: http://jfontain.free.fr/stooop.html)

Какие есть «сборки»?

Есть официальные исходные коды, которые любой желающий может скачать с официального сайта и собрать самостоятельно. Так же есть дистрибутивы от сторонних команд: ActiveState Tcl (проприетарный, есть платная версия, под все основные ОС: http://www.activestate.com/activetcl), WinTcl (более компактный, ориентирован на работу с ХОTcl, содержит Tloona и XOTcllde, как видно из названия - под Win: http://wintcltk.sourceforge.net/), TclKit (достаточно компактный дистрибутив, ориентированный на использование iTcl, обладает собран в один пакет и имеет систему управления собственным содержимым, кросс-платформенный: http://www.equi4.com/tclkit/), dqkit («TclKit на стеродидах, есть несколько вариантов сборки, кросс: http://sourceforge.net/projects/dqsoftware/) Tcl/Tk Aqua (дистрибутив заточен исключительно под MacOS: http://www.linkedin.com/in/danielsteffen/tcltk/). Недавно появилась достаточно занятная реализация Tcl для .Net (http://eagle.to/), отзывы вроде положительные - сам сказать ничего не могу, пока не ковырял. Если кто юзал -отпишитесь о впечатлениях.

Какую IDE взять?

Из личного опыта - лучше Vim'a пока не нашел. Под „винду“ - Komodo. GNU Emacs не сильно понравился, надо сильно допиливать. Tloona - не плохая среда, работал с ней мало, сказать ничего не могу, как впрочем и о XOTcllde. Для быстрой разработки с GUI прекрасно подходит Visual Tcl/Tk (vtcl) - форморисовалка а-ля Delphi с возможностью редактирования кода. В принципе удобная вещица, но не обязательна к использованию =), гуй на Тк пишется и так просто.

Какую литературу можно почитать?

По Tcl/Tk достаточно много англоязычных туториалов. Русский нашел только один (указал вышел). Из книг могу порекомендовать „Практическое программирование на Tcl и Tk, 4-ое издание“ (Б.Б.Уэлш, К.Джонс, Д.Хоббс), на английском - „Tcl and Tk Programming for the Absolute Beginner“ (Kurt Wall).

Пока все =), у кого есть желание поддержать топик - буду рад. Сам постараюсь в ближайшее время продолжить. Всем удачи!

Установка Tcl/Tk

0) Для Calculate Linux/Gentoo: emerge dev-lang/tcl, emerge dev-lang/tk, emerge dev-tcltk/tcllib

1) Для Fedora: yum install tcl tk

2) Для Ubuntu: sudo apt-get install tcl tk

3) Для Windows и MacOS: проще всего использовать бинарные дистрибутивы. Качаем любой и устанавливаем в два клика.

4) Сборка Tcl/Tk из исходников. Скачайте исходники (лежат отдельно для Tcl и отдельно для Tk) с оф.сайта и выполните следующие команды для каждого архива:

4.1 Распаковка исходных файлов: tar zxf имя_файла.tar.gz

4.2 Перейдите в папку командой: cd имя_файла && cd unix

4.3. Выполните: ./configure --prefix=/opt --enable-gcc (для Тк:./configure —with-tcl=../../tcl8.5a5/unix —prefix=/opt —enable-gcc) ; затем: make; потом: make test; и в завершениии: make install

Meerkat ()

>Так в Тикле все есть строка, а не символ.
В лиспе(если мы говорим о CL) все есть объект.
Не список, не символ, не атом даже, а «объект». Объект.
Cons-яйчека это объект, символ(symbol) это объект, пакет символов(package) это объект, литера(character) это объект, строка это объект, массив(array) это объект, число это объект, состояние ГПСЧ(*random-state*) это объект, функция это объект, метод обобщенной функции(generic function) это объект, комбинатор методов(method-combination) это объект, специализатор методов(specializer) это объект, тред(thread) это объект, процесс(process) это объект, путь(pathname) это объект, спецификация типа это объект(состоящий, как правило из объектов-cons-яйчеек и объектов символов), структура это объект, состояние(condition) это объект(и ошибки(error) и предупреждения(warning), как следствие - тоже), перезапуск(restart) это объект, поток(stream) это объект, таблица считывателя(*readtable*) это объект, класс это объект, и, разумеется, инстанс класса это тоже объект, не говоря уже о его слотах(standard-slot-definition). Причем, настоящий, а не как в C++ или Жабе каких-нибудь вонючих.

Love5an ()
Ответ на: комментарий от Love5an

Думаю Вам лучше знать. Я говорил скорее о классическом лиспе. К сожалению с промышленным знаком только поверхностно и ни в коем разе не хотел принизить данный язык.

Meerkat ()

Дополнил вики полезными ссылками. Пока мало, со временем буду добивать

Meerkat ()

Добавил в «Полезных ссылках» заметку о компилировании .tcl-файлов в .exe

Meerkat ()
Ответ на: комментарий от Meerkat

Добавил в «Полезных ссылках» заметку о компилировании .tcl-файлов в .exe

в .exe? на linux.org.ru?

jtootf ★★★★★ ()

уровень материала заставляет усомниться в его ценности. «кажется», «не ковырял», «работал мало» - может, стоило всё же поковырять, прежде чем писать FAQ? аргументация вида «не торт» и «костылестроение» вообще отбивает желание продолжеть чтение. что за клоунада?

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

> в .exe? на linux.org.ru?

Я думаю найдутся люди, которым может быть надо откомпилировать в .ехе. Ведь скрипты не только под *nix пишут).

уровень материала заставляет усомниться в его ценности. «кажется», «не ковырял», «работал мало» - может, стоило всё же поковырять, прежде чем писать FAQ? аргументация вида «не торт» и «костылестроение» вообще отбивает желание продолжеть чтение. что за клоунада?

Язык - согласен. Слишком «подзаборный» сейчас поправлю. На счет остального - вы и правда думаете, что один человек может испробовать все IDE и дистрибутивы в мире?) FAQ и создавался для того, чтобы его дополняли другие. Если буду делать только я - проще было на блог личный ссылку кинуть

Meerkat ()

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

очень плохо освящен

Стало быть, Tcl неправославен?

power ()

Заголовок исправь, а то эпик фейл

yoghurt ★★★★★ ()
Ответ на: комментарий от Love5an

...но при этом от встроенных типов наследоваться нельзя, прямо как в C++ или Жабе каких нибудь вонючих :)

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

Можно, если приперло, перегрузить validate-superclass и наследоваться хоть от fixnum, хоть от array. Только непонятно, нахрена это надо.

Love5an ()
Ответ на: комментарий от yoghurt

Какой именно? FAQ только начал формироваться. Поэтому материала мало, есть опечатки и т.п. Со временем буду дополнять, редактировать, править и т.п. Надо учитывать, что все это все же за вечер писалось, да и сама идея в течении часа возникла. Если есть тиклеры на ЛОРе - просьба помогать в наполнении FAQ. Пора уже популяризировать в нашей стране «Lisp on Drugs»

Meerkat ()

Вроде очистил от жаргонов.

uju ★★ ()
Ответ на: комментарий от Meerkat

>Какой именно?

Данного топика :) Хотя, уже поздно

yoghurt ★★★★★ ()
Ответ на: комментарий от Meerkat

Пора уже популяризировать в нашей стране «Lisp on Drugs»

зачем?

jtootf ★★★★★ ()
Ответ на: комментарий от Meerkat

FAQ и создавался для того, чтобы его дополняли другие

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

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

я по-прежнему не понимаю

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

dmsh ()
Ответ на: комментарий от Love5an

> Можно, если приперло, перегрузить validate-superclass и наследоваться хоть от fixnum, хоть от array. Только непонятно, нахрена это надо.

Отнаследуйте мне пожалуста cons-ячейку :-)

А надо это для того, чтобы эта новая cons-ячейка таскала с собой некую дополнительную инфу (допустим, о типе :-); при этом она должна работать как родная во все операциях типа car, cdr, nthcdr, ...

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от Love5an

> Тебе не надо наследоваться от cons-яйчейки.

Сегодня в колбасе потребности нет, я уже понял.

Ну так ты добровольно продемонстрируешь, что в лиспе «не как в C++ или Жабе каких-нибудь вонючих», или таки тебе предложить примеры, где нужно расширять именно консовскую ячейку?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

>что в лиспе «не как в C++ или Жабе каких-нибудь вонючих»,
В этом есть сомнения?

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


Ну, я тут насмотрелся на твои примеры на C++, лучше не предлагай.
Изменять built-in типы, а также функции, специальные переменные etc. в лиспе считается очень плохим стилем.

Love5an ()
Ответ на: комментарий от Love5an

>В этом есть сомнения?

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

Изменять built-in типы, а также функции, специальные переменные etc. в лиспе считается очень плохим стилем.

Я *не просил* изменять. Я просил *отнаследовать*.

При этом built-in поведение *должно* остаться *абсолютно* тем же, а вот некоторые новые функции будут читать (и возможно писать при создании) в конс-ячейке новую инфу.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

>Если отнаследовать конс-ячейку ты не сможешь, то она не настоящий объект, а суррогат, тот же самый, что в вонючих жабе и плюсах.

Это объект в любом случае. У него в рантайме есть тип и identity. На него можно специализировать методы. В CL всё - объекты. Даже самый вонючий fixnum. Это к наследованию не относится.
В жабе же, и плюсах, особенно, встроенные типы - просто куча битов(ну в жабе боксится, да, но см. про методы).

Love5an ()
Ответ на: комментарий от Love5an

Ха ха , зайдя в тему «tck/tk-lor-faq» и что мы видим ? ))
Ога, Ничего нового, до тошноты ..
Пачкуале Пестрини заняты своим обычным делом.

elipse ★★★ ()
Ответ на: комментарий от Love5an

> В CL всё - объекты. Даже самый вонючий fixnum. Это к наследованию не относится.

Да-да, поведай нам еще об объектах без наследования!

Это не объекты. На что тебе смоллтолкер yoghurt тонко намекнул.

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от elipse

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

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

В общем мое мнение — разжаловать этот якобы faq в обычную тему, ТС написать политкорректную версию и снова запостить.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> обосновывая полезность тикля тем, что он лучше лиспа.

Я это не заметил. Может, покажете это место в тексте ?

elipse ★★★ ()
Ответ на: комментарий от elipse

> Я это не заметил. Может, покажете это место в тексте ?

«Tcl - Lisp On Drugs», что по-русски в данном контексте будет «Tcl это Lisp на стероидах»

Если бы Drugs означало вещества/наркотики, то ТС не стал бы вспоминать такое негативное сравнение с лиспом.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

>Да-да, поведай нам еще об объектах без наследования!

Это объекты. Объект это то, что имеет identity(и, соответственно, состояние) и тип(и, соответственно, поведение). Кроме того, почему без наследования?

(describe (find-class 'cons))
;; ...
;; Class precedence list: CONS, LIST, SEQUENCE, T
;; Direct superclasses: LIST
;; No subclasses.
;; ...

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

Ну давай, специализируй мне метод int(виртуальную функцию, я имею ввиду). Хотя нет, сначала добавь ему новый метод.

В лиспе запросто:

(defgeneric foo (x))

(defmethod foo ((x integer))
  (format t "~a is an integer" x))

Love5an ()
Ответ на: комментарий от www_linux_org_ru

Хе хе, т.е., упомянуть Lisp (и без наркоты) уже как унижение проходит ?
А что Tcl тут в негативе, так это мы не видим , да ?))

elipse ★★★ ()
Ответ на: комментарий от www_linux_org_ru

«Tcl - Lisp On Drugs», что по-русски в данном контексте будет «Tcl это Lisp на стероидах»

мне определённо нравится твоё обращение с контекстом; это очень удобно - видеть именно то, что хочется увидеть :)

jtootf ★★★★★ ()

Какие есть реализации Tcl/Tk?

Как таковой Так-тикль один, его разработку сегодня ведет Tcl Core Team, но существуют так же расширения для него: стандартная реализация Tcl (http://www.tcl.tk/), экзотикль (XOTcl: http://media.wu-wien.ac.at/, расширение для ООП), iTcl (Первое ООП расширение, Inct Tcl, на нем написана iWidgets: http://incrtcl.sourceforge.net/), SNIT (объектный клей для Tcl, включен в стандартную библиотеку Tcl, оф.документация: http://www.wjduquette.com/snit/snit.html), STOOOP (ООП-расширение написанное на Tcl, так же сегодня входит в стандартную библиотеку, оф.документация: http://jfontain.free.fr/stooop.html)

какой-то некорректный ответ на свой-же вопрос :) то есть вопрос про реализации, ответ про расширения..реализации упомянутый http://www.tcl.tk, Jim (ещё больше ориентирован на встраивание) http://wiki.tcl.tk/13693, http://jim.berlios.de/

incrTcl скорее мёртв чем жив; SNIT достаточно оригинальная вешч - ОО без наследования воообще (можно наследоваться только непосредственно от трёх верхних классов, далее - делегирование). Неупомянут механизм поддержки ОО - TclOO который теперь входит в спецификацию языка и поддерживается на уровне базовых процедур.

автору: 1) проверь грамматику русского языка, а то он на уровне средней школы с массой ошибок. 2) внешние ссылки надо дублировать ссылками на страницы wiki.tcl.tk - так корректнее.

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

incrTcl скорее мёртв чем жив;

Ах ты ж боже мой ! Ну и кто бы мог такое подумать ?)):

http://wiki.tcl.tk/19873

apw - 2010-03-19

There is a new beta release of itcl-ng available (mostly bug fixes). This will be integrated into tcl 8.6b2 (at least I hope so).

itcl 4.0b4 cvs sources are available here [9] or the source package releases (itcl4.0b4 and itk4.0b4) at [10].

LV so, is this new beta release different than what is already present in Tcl 8.6 beta?

apw yes

elipse ★★★ ()
Ответ на: комментарий от Love5an

> Кроме того, почему без наследования? (describe (find-class 'cons)) ...

Не вижу определение наследника класса cons. И краткого примера использования.

Ну давай, специализируй мне метод int(виртуальную функцию, я имею ввиду).

Сначала разберись с лиспом.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от elipse

> Хе хе, т.е., упомянуть Lisp (и без наркоты) уже как унижение проходит ?

«на стероидах» означает более накачанный, чем без оных

А что Tcl тут в негативе, так это мы не видим , да ?))

и как оно будет по-русски в твоем переводе?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от jtootf

> мне определённо нравится твоё обращение с контекстом; это очень удобно - видеть именно то, что хочется увидеть :)

я определенно не верю, что повторяя аж 2 раза фразу Lisp on Drugs, ТС имел в виду какой-нить перевод типа «тикль это лисп под капельницей»

www_linux_org_ru ★★★★★ ()

> Можете. Tcl позволяет писать в функциональном стиле.

ммм... там есть библиотека, позволяющая использовать lazy evaluation и как-то недопускать побочные эффекты?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

я определенно не верю

ты как раз веришь, но не думаешь. вот оригинал этой фразы с контекстом:

http://www.shlomifish.org/humour.html#tcl_is_lisp_on_drugs

а в сообществе её употребляют в смысле «Lisp под веществами», подчёркивая ненормальность языка по сравнению с академическим и заумным предком. и, кстати, вот:

http://answers.yahoo.com/question/index?qid=20090824180703AAZye54

я думаю, ответ очевиден

jtootf ★★★★★ ()
Ответ на: комментарий от elipse

incrTcl скорее мёртв чем жив;

Ах ты ж боже мой ! Ну и кто бы мог такое подумать ?)):

если кто-то насилует труп и этот труп колышится, ещё не значит что он жив :) в текущем состоянии itcl валится и глючит даже в ActiveState сборках :(

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

> в текущем состоянии itcl валится и глючит даже в ActiveState сборках

1. фигня какая, а в Debian не валится , не валятся и мегавиджеты в дистре на itcl.

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

2. по быстродействию на сегодня xotcl -> itcl ->, ... а потом и все остальное.

3. на itcl написано УЖЕ кода больше чем на все остальных инкарнациях oo tcl разом взятых.

4.только у itcl пока есть нормальная документация, а не рекламные листки

5. itcl - старый конь борозды не портит, и достаточно УЖЕ изучен и в наличии масса примеров использования.

6. для старых tcl (8.4 , 8.5) - itcl наиболее обкатанный и проверенный выбор.


elipse ★★★ ()
Ответ на: комментарий от www_linux_org_ru

Отнаследуйте мне пожалуста cons-ячейку :-)

Чтобы cons-ячейку можно было отнаследовать, её нужно хотя бы для начала уметь создать (make-instance). В CLOS built-in типа годятся только для специализации.

А надо это для того, чтобы эта новая cons-ячейка таскала с собой некую дополнительную инфу (допустим, о типе :-); при этом она должна работать как родная во все операциях типа car, cdr, nthcdr, ...

car, cdr, etc - не методы класса.

mv ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

При этом built-in поведение *должно* остаться *абсолютно* тем же, а вот некоторые новые функции будут читать (и возможно писать при создании) в конс-ячейке новую инфу.

В сишном мире это больше похоже на: «Отнаследуйся от пойнтера. При этом built-in поведение должно остаться абсолютно тем же, а вот некоторые новые функции...» и т.д. Cons - это не только объект, но ещё и стратегия аллокации, поэтому было бы странно ожидать нормальной работоспособности функций с объектом, физически устроенным по-другому.

Кстати, lisp object и clos object всё-таки следует разделять.

Зато в лиспе (цл) есть символы, и всякую левую лабуду можно навешивать как раз на символы:

(defvar foo (cons 1 2)) => FOO

(setf (get (symbol-plist 'foo) :сколько?) 'поллитра)

(get (symbol-plist 'foo) :сколько?) => ПОЛЛИТРА

Соответственно, левое содержимое plist на работоспособность built-in функций абсолютно не влияет.

mv ★★★★★ ()
Ответ на: комментарий от mv

> В сишном мире это больше похоже на: «Отнаследуйся от пойнтера

Но никто в здравом уме, в отличиет от Love5an, не утверждает, что в „с++ все есть объект“, и потом не пытается доказать, что „тебе не надо наследоваться от пойнтера“.

Кстати, я время от времени размышляю, как бы расширить спецификацию с++ так, чтобы было можно наследоваться от char, и при этом НЕ ТОРМОЗНУТЬ рантайм там, где это наследование не используется.

Cons - это не только объект, но ещё и стратегия аллокации, поэтому было бы странно ожидать нормальной работоспособности функций с объектом, физически устроенным по-другому.

Насколько я понимаю, конс-ячейка не больше объект, чем плюсовый double.

Кстати, lisp object и clos object всё-таки следует разделять.

да.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

Нет. В лиспе всё есть объект.
Состояние, identity, поведение.

Твои попытки доказать, что, несмотря на то, что С++ - обоссаное дерьмо, CL - не лучше - проваливаются раз за разом. Выучи CL уже, наконец.

Love5an ()
Ответ на: комментарий от www_linux_org_ru

Но никто в здравом уме, в отличиет от Love5an, не утверждает, что в «с++ все есть объект», и потом не пытается доказать, что «тебе не надо наследоваться от пойнтера».

Базовые типы в обоих языках в их объектных системах находятся на птичьих правах. C++ и CL проектировались, чтобы работать быстро, поэтому разработчикам пришлость пойти на множество trade-off. К тому же, в CL объектная система - не единственная и не главная парадигма. Да и вообще, это просто библиотека, хоть и популярная.

Кстати, я время от времени размышляю, как бы расширить спецификацию с++ так, чтобы было можно наследоваться от char, и при этом НЕ ТОРМОЗНУТЬ рантайм там, где это наследование не используется.

Зачем?

Насколько я понимаю, конс-ячейка не больше объект, чем плюсовый double.

В CL объект обладает рантаймной информацией о типе. В плюсах этого нет, там базовые сишные типы представлены в их натуральном виде. Лисповый компилятор частные оптимизации иногда делает, типа размещения в регистре объекта, развёрнутого в машинный вид, но сути это не меняет.

mv ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

Но никто в здравом уме, в отличиет от Love5an, не утверждает, что в «с++ все есть объект»

Вот, кстати, забыл сказать, что «объект» и «наследование» между собой никак не связаны. И даже «объект» и «класс» никак не связаны. Вот гражданин Love5an как раз про это и говорит.

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

mv ★★★★★ ()
Ответ на: комментарий от mv

> Вот, кстати, забыл сказать, что «объект» и «наследование» между собой никак не связаны.

Ага, «никак не связаны»

In object-oriented programming (OOP), Inheritance is a way to compartmentalize and reuse code by creating collections of attributes and behaviors called objects which can be based on previously created objects. http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

Вот, кстати, забыл сказать, что «объект» и «наследование» между собой никак не связаны.

Слово «объект» не имеет общепринятого определения. Да, словом «объект» иногда пользуются в более широком смысле, например, называя им все, что лежит в памяти и имеет хоть какое-то indentity.

Love5an определенно использовал иное, более узкое, толкование этого слова, уточнив «Причем, настоящий, а не как в C++ или Жабе».

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

www_linux_org_ru ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.