Наступает на пятки необходимость общения между собой очень гетерогенных систем , на что были направленны усилия по разработке веб сервисов , CORBA и т.д.
То есть счас усилия сводятся к построению мостов между системами .
Возможно следующие разработки будут в том или ином виде (как библиотеки , скриптовые языки) направленны не просто на общение гетерогенных компонентов , а на построении отношений между ними. Вместо использования статики , отношения между компонентами могли бы возникать в динамике.
Шаги в этом плане уже делаются , тот же рефлекшен то же описание объектов на XML и т.д Все это ведет к тому что компоненты системы представляют свое МЕТА описание.
Ведь на сегодняшний день например существует невероятная масса утилит которые решаю огромное к -во проблем . Но даже продвинутому юзеру найти среди всего потока информации нужную библиотеку , утилиту сновится трудно. Было бы очень удобно переложить этот поиск на чьито плечи.
Тогда напрмиер программа для рипания CD дисков будет представлять из себя набор скриптов , которые обращаются к компонентам системы по мере надобности. Понадибился какой то кодек, опросили систему , подключили в рантайме , вевели доступные свойства . Если не нашли кодека , полезли в инет , разыскали там нужное нам описание и т.д.
Т.е. Язык который бы взял на себя работу по МЕТА описанию компонентов (объектовб функций ) и из взаимодействию.
Возможно я далек от реальности , но в скором времени мощности систем невероятно вырастут , прорускные каналы станут на порядок быстрее , и главным вопросом станет не создать компонент , а найти подходящий и связать с другим.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Заметим в скобках, что именно это произошло с Perl, Python, PHP, Ruby
ПК>Это все динамически типизированные языки.
А некоторые даже динамически не очень типизированны.
>> Не исключено, что в "чем-то новом" вааабще не будет понятие такого — типизация
ПК>Вряд ли мы до настолько нового доживем
+1
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, Odi$$ey, Вы писали:
OE>>>Идентичность по решаемым задачам есть.
AVK>>Это не то. Потому что куда более важную роль в выборе играет функционал
OE>это и есть "Идентичность по решаемым задачам"
Нет, это идентичность по тому, как эти задачи решаются. Если в одном продукте задача Х решается просто и непринужденно, а в другом через задницу, то это совсем не означает что продукты функционально идентичны. Иначе получается что C# функционально идентичен любому продукту, на нем написанному.
AVK>>и стабильность. И только потом производительность.
OE>для кого-то потом, для кого-то сначала
Я таких не видел. Толку от сверхпроизводительности, если пользоваться неудобно и падает каждые десять минут, притом еще и доделан будет завтра. Все в конечном счете сводится к экономической эффективности, а ее можно оценить. И де факто железки сейчас значительно дешевле, нежели софт (если только софт, конечно, не тиражируется десятками миллионов копий).
AVK>>Загрузка каналов связи к языку программирования имеет весьма слабое отношение.
OE>ну, мы здесь
как-то плавно перешли на "потребление софтом ресурсов"
Я никуда не переходил. Я по прежнему не согласен с утверждением, что производительность на рынке сейчас востребована настолько, что не подходят управляемые платформы, на основании того что всегда есть полностью идентичный софт на неуправляемой платформе с лучшей производительностью.
OE>>> А "главный" критерий для каждого покупателя разный. AVK>>Но тенденция имеется.
OE>не знаю насчет тенденции, но такого, чтоб можно было забить на требования к ресурсам потому что мой софт единственный и неповторимый — это а) должно очень и очень повезти б) врядли продлится долго
Забивать никто не предлагал. Но любой софт это компромисс между функционалом, непрожорливостью и стабильностью. Тенденция в том, что золотая середина начинает смещаться от непрожорливости в сторону двух других.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, minorlogic, Вы писали:
M>Возможно я далек от реальности , но в скором времени мощности систем невероятно вырастут , прорускные каналы станут на порядок быстрее , и главным вопросом станет не создать компонент , а найти подходящий и связать с другим.
Ты забываешь про один важнейший аспект любой информационной системы — ее архитектуру. Уже сейчас на нее тратится весьма заметный кусок усилий. Дальше ее роль будет только возрастать. А компоненты спасают только от затрат на кодирование. Если не думая слепить компоненты в кучу, то ничего хорошего из этого не получится.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
OE>>это и есть "Идентичность по решаемым задачам" AVK>Нет, это идентичность по тому, как эти задачи решаются. Если в одном продукте задача Х решается просто и непринужденно, а в другом через задницу, то это совсем не означает что продукты функционально идентичны. Иначе получается что C# функционально идентичен любому продукту, на нем написанному.
лихо загнул, я не понял но чуствую продолжать про функционал смысла не имеет
AVK>>>и стабильность. И только потом производительность. OE>>для кого-то потом, для кого-то сначала AVK>Я таких не видел.
я видел. "Вот наша техника — будет работать на ней? давайте посмотрим что там у вас"
AVK>>>Загрузка каналов связи к языку программирования имеет весьма слабое отношение. OE>>ну, мы здесь
как-то плавно перешли на "потребление софтом ресурсов"
AVK>Я никуда не переходил.
ok, программируя на Oracle Forms Developer в принципе не возможно достичь того трафика между клиентом и oracle-сервером, как на C++/OCI. Если клиенты за модемами с паршивенькими линиями это может быть решающим фактором в выборе продукта.
AVK>Я по прежнему не согласен с утверждением, что производительность на рынке сейчас востребована настолько, что не подходят управляемые платформы, на основании того что всегда есть полностью идентичный софт на неуправляемой платформе с лучшей производительностью.
OE>>>> А "главный" критерий для каждого покупателя разный. AVK>>>Но тенденция имеется.
OE>>не знаю насчет тенденции, но такого, чтоб можно было забить на требования к ресурсам потому что мой софт единственный и неповторимый — это а) должно очень и очень повезти б) врядли продлится долго
AVK>Забивать никто не предлагал.
значит показалось
AVK>Но любой софт это компромисс между функционалом, непрожорливостью и стабильностью. Тенденция в том, что золотая середина начинает смещаться от непрожорливости в сторону двух других.
Здравствуйте, Пацак, Вы писали:
ZEN>>б) смешивание (mixins);
П>Кстати любопытно: интересная ведь концепция, но почти нигде не получила распространения. Интерфейсы — пожалуйста, mixins — фигушки. Интересно, почему?
В Ruby применяется активнейшим образом, начиная от самых базовых классов и стандартной библиотеки.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
"henson" <3702@users.rsdn.ru> wrote in message news:1400899@news.rsdn.ru... > Здравствуйте, iZEN, Вы писали: > > ZEN>Что мне не нравится в ОО-ориентированном языке — это слишком сильная связь между предком и потомками, которая ужасна и неэффективна в глубокой иерархии. 70% кода в этом случае, как правило, — просто балласт и никогда не работает.
Уточню.
Наследование, которое влечет за собой сильную связь мужду объектами, является издержком реализаций ОО.
ОО же изначально не имеет понятия наследования; есть объекты, реагирующие на сообщения одного типа.
Здравствуйте, Павел Кузнецов, Вы писали:
>> ПК>Собственно, на самом деле меня больше интересует не (только) инновационная ценность нового языка, а вероятность принятия индустрией нового языка, за которым не стоят такие "монстры" как Sun или Microsoft, и факторы, которые должны для этого "сработать"... >> >> Заметим в скобках, что именно это произошло с Perl, Python, PHP, Ruby
ПК>Это все динамически типизированные языки. Того же (пока?) не происходит с тем же D.
"Неужели, мессир, в праздничную ночь гостей за столом разделяют на два сорта? Одни — первой, а другие, как выражался этот грустный скупердяй-буфетчик, второй свежести?"
Ты просил — вероятность принятия индустрией нового языка, за которым не стоят монстры
Я ответил
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты забываешь про один важнейший аспект любой информационной системы — ее архитектуру. Уже сейчас на нее тратится весьма заметный кусок усилий. Дальше ее роль будет только возрастать. А компоненты спасают только от затрат на кодирование. Если не думая слепить компоненты в кучу, то ничего хорошего из этого не получится.
Ты меня совсем не понял , я говорил ИМЕННО про язык который бы облегчал создане архитектуры приложения , который бы брал на себя рутинные обязанности по подгонке друг к другу отдельных программных компонент.
Как бы отдалял нас от проблем связанных с реализацией , и наоборот приближал и формулировал создание архитектур. Некий язык работающий с МЕТА информацией.
Ну раз уж так, и я скажу.
1) Должен быть компонентным. Надеюсь компонент не надо сравнивать с классом?
2) Должно быть наследование классов. Если нет наследования, то общественность это не поймет. Даже не рассуждая наследование плохо или хорошо, общественное мнение главнее.
3) Должен поддерживать все основные фичи процесса построения приложений. То есть, как минимум обладать большинством фич UML. И не противоречить ему.(RUP-подобные постановки еще главенствуют и я думаю будут продолжать главенствовать).
4) Должен быть поддержан большой корпорацией. Пользователи языка должны быть уверены, что язык не умрет и не будет оставаться академическим опытом. И корпорация должна отвечать за качество реализации компилятора(что очень немаловажно).
5) Должно быть достаточно большое количество библиотек. Это можно даже сказать правило определяющее. При выборе языка, нужно быть уверенным что можно найти библиотеку на все случаи жизни.
Все остальное, типа mixin и т.д. — всего лишь конфетки, которые скрашивают нашу жизнь, но не определяют общую линию партии. В общем, бизнес — есть бизнес.
ZEN>Что мне не нравится в ОО-ориентированном языке — это слишком сильная связь между предком и потомками, которая ужасна и неэффективна в глубокой иерархии. 70% кода в этом случае, как правило, — просто балласт и никогда не работает.
Ты просто неумеешь их готовить. Наследование опасно в неумелых руках, но в умелых оно спасает до 70 процентов ООП проекта(оценка из башки, но можно и померить). Ничего лучше чем функциональная декомпозиция, человечество в ООП не придумало. Другой вопрос, что при этом человечество забывает принципы Барбары Лисков, и забывают инкапсуляцию классов в наследовании друг от друга. А ведь все для этого в современных языках есть. private, protected — вполне достаточные инструменты чтобы это обеспечить.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты забываешь про один важнейший аспект любой информационной системы — ее архитектуру. Уже сейчас на нее тратится весьма заметный кусок усилий. Дальше ее роль будет только возрастать. А компоненты спасают только от затрат на кодирование. Если не думая слепить компоненты в кучу, то ничего хорошего из этого не получится.
С некоторых пор, я не уверен что именно требования и архитектура являются определяющими при выборе платформы. По моим наблюдениям, когда все только начиналось, выбор платформы Net было всегда политическим решением. И принималось до готовности постановки. А выбор между Net и Java и их соответсвующими компонентами — определяют архитектуру(хотя они все больше сходятся).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
AVK>>>Боюсь что нет. Сложность современного софта настолько велика, что вероятность того, что два независимых производителя выкатят в одно время идентичный софт равна нулю. Ты вот приведешь примеры такого софта? GZ>>Сходу? Системы документооборота в нашей стране(поскольку в основном работаю в данной области).
AVK>Ну и? Какие из них, по твоему, идентичны?
Дело в том, что фич в документообороте немного(они просто большие по объему). А вот поставщиков до фигищи. И достаточно много, которые держат все из этих фич. А пользователей таких систем не так уж много и они все достаточно крупные. Поэтому на этом рынке высокая конкуренция, и смена поставщиков решений достаточно частый факт. Я не слишком связан с процессом продаж, но знаю по крайней мере один случай, который произошел именно из-за недостаточной производительности решения. Называть фирмы и поставщика считаю неэтичным.
Здравствуйте, AndrewVK, Вы писали:
AVK>Боюсь что нет. Сложность современного софта настолько велика, что вероятность того, что два независимых производителя выкатят в одно время идентичный софт равна нулю. Ты вот приведешь примеры такого софта?
Так что вопрос в том, что считать идентичностю продуктов. Для одного продукты разные, а для друго важно, что они одинаково успешно решают сходные задачи. Так для фаната HL2 конечно D3 совсем другой продукт. А для меня и то, и то развлекуха на пару дней. Ну, и если один из продуктов работает быстрее, то ему явно светит более широкий рынок. Не у все же видюхи за 500 баксов?
Так тут то он скорее прав. Что нельзя сказать про общий смысл его высказывания.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>a) сильная инкапсуляция; ZEN>б) смешивание (mixins);
Класс! Постановка в один список базовых свойств и частных фич! Отпадная логика!
ZEN>2) Независимым от платформы — компиляция в промежуточный код. ZEN>3) Иметь простую виртуальную машину для выполнения кода (грубо: модель процессора со стэковой архитектурой).
А почему не сложную (рубо: на базе комбинаторной логики и каких-нить сверток графов)?
Зачем вообще привязывать свое видение реализации к анализу требований?
ZEN>4) И самое главное, чтобы исходники программы на этом языке легко читались ЧЕЛОВЕКОМ. ZEN>И тогда создание поистине всемирных библиотек кода на этом языке можно сделать по принципу Wikipedia. И Сеть будет Компьютером.
+1
Вот это красивая мечта.
ZEN>Что мне не нравится в ОО-ориентированном языке — это слишком сильная связь между предком и потомками, которая ужасна и неэффективна в глубокой иерархии. 70% кода в этом случае, как правило, — просто балласт и никогда не работает.
Все уже поняли, что ты ратушь за миксины. Но не нужно делать это навязчивой идеей.
К тому же есть более общие навязчивые идеи. Например, идея расширяемых языков и метапрограммирования позволит сделать и миксины, и foreach, и черта лысого. И все это без изменения самого языка!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Очень вкратце и упрощая, там обсуждается статья о том, что наиболее новые и распространенные языки (Java, C#) не привносят в индустрию ничего нового, а являются объединением давно известных и используемых идей. (Таким же объединением был некогда PL/I. Судьба его печальна.)
PL/1 был монстром, в который запихнули всё, что пришло в голову, при этом реализация этого всего зачастую принимала самые причудливые формы. При этом, вобрав в себя все фичи своего времени, PL/1 не делал программирование на много проще. Java и C# делают.
Я думаю, что любое промышленное решение, включая языки программирования, нужно рассматривать не с точки зрения привнесения в индустрию нового, а с точки зрения упрощения самого процесса производства и увеличения конечной производительности программистов. Если это будет являться результатом введения в язык новой парадигмы — отлично, если это будет всего лишь введение дополнительных типов типа string, фич аля property или таких вещенй как reflection, которые позволяют решать задачи быстрее и проще, то этого уже достаточно.
Что же касается нового, то лично мне прежде всего хотелось бы видеть в языках встроенную поддержку генерации паттернов. AOP отчасти это делает, но, к сожалению, его практические возможности не идут на много дальше тех примеров, которые упоминаются при объяснении что это такое, типа логирования и обработки исключений.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>И последнее: лично мне наиболее современным и "впередсмотрящими" языками представляются не тяжеловесные "все-в-одном + своя платформа + вообще-все-что-вам-может-понадобиться-когда-либо" Java и C#, а более легковесные, без груза "обратной совместимости по парадигме", приспособленные к сегодняшнему миру Python и Ruby.
Не хочу пытаться стать провидцем и предсказывать будущее. Я не знаю, какие языки могут появится и какое их ждет будущее. Честно говоря меня это и не интересует. Языки программирования делятся для меня на две категории -- те, которые я использую, и те, которые пытаюсь придумать. Последнее у меня не шибко получается, поэтому позволю себе сосредоточить внимание читателей форума на языке Ruby. Чтобы показать одну из черт этого интересного языка, которую сейчас я считаю в Ruby наиболее важной. И которая, как мне кажется, имеет непосредственное отношение к затронутым DarkGray вопросам в Re: Следующий язык программирования
Начну немного издалека. Когда-то давным давно я разработал для себя свою систему управления компиляцией C++ проектов. Ее главная идея была в том, чтобы проектные файлы представляли из себя не декларативные описания, а программы на специализированном скриптовом языке, чтобы можно было естественным образом учитывать в проекте особенности конкретных компиляторов на конкретных платформах. Год назад мне потребовалось перевести эту систему на новую экзотическую платформу и я задался вопросом: "Имеет ли смысл продолжать использовать собственный скриптовый язык или же лучше взять какой-либо из существующих?". Я решил взять готовый. Оставалось выбрать какой. Просмотрел массу вариантов (даже с языком c-smile знакомился ), но в результате выбор пришлось делать из Perl, Python и Ruby, т.к. они уже были на данной платформе. Ни на одном из них я не программировал, знания Perl и Python были поверхносными, про Ruby знал только то, что он по-умолчанию ставился вместе с FreeBSD 4.5 и что в этой версии FreeBSD какие-то системные скрипты были написаны на Ruby. Тем не менее, я выбрал Ruby.
Почему? Из-за одной его супер-мега-фичи: возможность передавать в функцию блок кода в качестве параметра. Без синтаксического оверхеда. Что позволяло получать декларативные описания из чистого императивного кода. Например, следующее описание проекта
Оба варианта похожи, не правда ли? Тем не менее вариант на Ruby -- это программа, готовая к исполнению. Вот так я, сам того не подозревая, создал первый для себя Domain Specific Language с помощью Ruby. Самое важное здесь то, что DSL-программа при этом является абсолютно корректной Ruby-программой. Собственно вокруг этого и пойдет дальнейший разговор.
Со временем в Ruby обнаружились еще несколько возможностей для удобного создания DSL-ей. Наиболее простая из них -- это способ передачи в методы аргументов и такие важные Ruby типы, как Hash и Array. А так же связанный с этим синтаксический сахар языка Ruby. Например, следующая запись:
Эта особенность неоценима при создании DSL -- с ее помощью можно делать декларации со списками необязательных свойств (см. так же пример в Re: Вот такой вот препроцессор.
Но еще важнее оказались возможности Ruby по метапрограммированию. В частности, работа с метаклассами, которая хорошо описана в Seeing Metaclasses Clearly (однако, для ее понимания требуется серьезное знание языка Ruby). В частности, одиним из самых распространенных приемов метапрограммирования в Ruby является создание метаметодов, которые можно использовать в декларациях производных классов. Вот пример из упомянутой статьи:
class MailTruck
def self.company( name )
meta_def :company do; name; end
end
end
объявляется класс MailTruck, в котором содается метаметод company. Особенность этого метаметода в том, что он может применяться только в декларациях производных классов. За вызовом "meta_def :company ... end" скрывается достаточно сложная, но лаконичная механика, смысл которой -- объявление в производном классе обычного метода с именем company:
class HappyTruck < MailTruck
company "Happy's -- We Bring the Mail, and That's It!"
end
Это описание производного класса, в котором странная запись "company ..." на самом деле является вызовом метаметода company из базового класса. А в результате мы имеем возможность делать так:
h = HappyTruck.new
h.company
т.е. создаем объект типа HappyTruck и вызываем у него метод company. Результатом которого является строка "Happy's -- We Bring the Mail, and That's It!". Но ведь мы не определяли метод company у класса HappyTruck -- за нас это сделал метаметод. Т.е. приведенная выще декларация класса равносильно более традиционной:
class HappyTruck < MailTruck
def company
"Happy's -- We Bring the Mail, and That's It!"
end
end
Приведенный выше фокус с метаклассами и метаметодами применяется в Ruby повсеместно. Например, на его основе в стандартной библиотеке Ruby сделаны вспомогательные методы для объявления и реализации getter/setter-ов. Так, запись:
class My
attr_accessor :my_attr
end
на самом деле эквивалент:
class My
# Метод getter.
def my_attr
@my_attr
end
# Метод setter.
def my_attr=( v )
@my_attr = v
end
end
Еще интереснее в стандартном классе Date реализован метаметод once -- он позволяет сделать так, чтобы вычисления какого-то метода выполнялись только однократно. Например, запись:
class Date
...
once :day_fraction
...
def day_fraction
<какие-то вычисления>
end
...
end
была эквивалента:
class Date
def calc_day_fraction
<какие-то вычисления>
end
def day_fraction
# Вычисляем атрибут @day_fraction только если он не был вычислен ранее.
@day_fraction = calc_day_fraction unless @day_fraction
@day_fraction
end
end
Но еще дальше использование метаметодов ушло в проекте Ruby on Rails, в частности, в одной из его библиотек, ActiveRecord (библиотека для организации object-relation mapping-а). Например, следующая запись:
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_and_belongs_to_many :categories
end
приводит к объявлению в классе Project методов (нотация Class#method означает не статический метод method у класса Class):
Т.е. в результате всего нескольких строчек в декларации, класс Project снабжается набором методов для работы с SQL таблицей и ее асоциациями.
Итак, я перечислил несколько специфических особенностей языка Ruby, которые позволяют достигать черезвычайно интересного эффекта -- созание на Ruby новых DSL, которые при всем, при том, остаются языком Ruby. Т.е., появляется что-то, что уже было на Lisp-е, но с важными, имхо, отличиями:
В отличии от Lisp-а Ruby остается чисто императивным языком с превычным большинству программистов синтаксисом. Для меня это означает, во-первых, что не требуется адаптации к птичьему Lisp-синтаксису и, во-вторых, что на Ruby можно писать нормальный императивный код.
В отличии от Lisp-а имеется одна основная ветвь разработки Ruby и одна единая реализация, портированная на массу платформ. Еще более важно, что есть единая стандартная библиотека (постоянно и оперативно развиваемая) и централизованная вокруг Ruby community. Достижением этого community является, например, система управления пакетами RubyGems.
Все это позволяет, во-первых, легче входить в язык. Во-вторых, существует всего один диалект Ruby, поэтому написанная на одной платформе библиотека оказывается доступной и для других платформ. Что способствует обеспечению Ruby необходимыми библиотеками.
. Имхо, перечисленные мной особенности языка Ruby делают возможным создание на Ruby многоуровневых DSL. Т.е. вполне реально получить листинг, который показывает общий ход решения задачи. Это будет всего лишь программа на самом высокоуровневом DSL. Которая, в свою очередь будет написана на чуть менее высокоуровневом DSL. И т.д. Но все эти программы в то же время будут являтся всего-лишь Ruby программами.
Вот такой вот язык. Который существует здесь и сейчас. Портирован на массу платформ. Имеет уже сложившуюся и постоянно увеличивающуюся community. И который, вообще-то говоря, уже доказал свою жизнеспособность. В том, что он станет мейнстримом и потеснит Java c C# лично я сомневаюсь. Но вот то, что он может стать толчком для чего-то нового -- вот на это я надеюсь.
GlebZ,
> 4) Должен быть поддержан большой корпорацией. Пользователи языка должны быть уверены, что язык не умрет и не будет оставаться академическим опытом.
Как следует из опыта, поддержка корпорацией вовсе не означает, что язык не умрет. Свежий пример -- VB, имевший большую базу пользователей, и убитый большой корпорацией.
> Наследование опасно в неумелых руках, но в умелых оно спасает <...>
В умелых его стараются заменять менее сильными связями.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
E>class MailTruck
E> def self.company( name )
E> meta_def :company do; name; end
E> end
E>end
E>
E>объявляется класс MailTruck, в котором содается метаметод company. Особенность этого метаметода в том, что он может применяться только в декларациях производных классов. За вызовом "meta_def :company ... end" скрывается достаточно сложная, но лаконичная механика, смысл которой -- объявление в производном классе обычного метода с именем company: E>
E>class HappyTruck < MailTruck
E> company "Happy's -- We Bring the Mail, and That's It!"
E>end
E>
E>Это описание производного класса, в котором странная запись "company ..." на самом деле является вызовом метаметода company из базового класса.
На самом деле это описание добавляет статический (в терминологии C++/Java) метод company в класс HappyTrack. Что позвляет писать:
HappyTruck::company
Для того, чтобы метод company был не статическим методом класса HappyTrack и можно было бы писать: E>
E>h = HappyTruck.new
E>h.company
E>
реализацию метаметода company в MailTruck следовало переписать так:
class MailTruck
def self.company( name )
class_def :company do; name; end
end
end
Приношу свои извинения.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
AVK>>Ну и? Какие из них, по твоему, идентичны? GZ>Дело в том, что фич в документообороте немного(они просто большие по объему).
Я бы так не сказал. Одно количество и качество поддержки форматов документов многого стоит.
GZ> А вот поставщиков до фигищи.
Да тоже не дофига (если не считать конечно тех, кто лепит такие системы на базе покупной платформы). Основная масса решений пользует какой нибудь документум или лотус.
Здравствуйте, VladD2, Вы писали:
VD>ВDB2, MSSQL, Oracle.
Тут согласен. Но это исключение.
VD>IDEA, VS, Eclips.
Ага. И все, что характерно, сильно отличаются не только по фичам, но еще и по целевым языкам. А Eclipse как платформа вобще бесплатен.
VD>Half Life 2, Doom 3, Хроники Ридека...
Тоже мимо. Не думаю что кто то среди них будет выбирать по производительности.
VD>Так что вопрос в том, что считать идентичностю продуктов.
Это когда они настолько похожи, что единственное, что волнует потребителя, это производительность.
но чуствую продолжать про функционал смысла не имеет
Если нам не помогут, то мы тоже никого не пощадим.
