Здравствуйте, WFrag, Вы писали:
WF>И еще, объясни, чем эта концепция definition-implementation-object отличается от C++-ых классов?
Только definition — является единицей наследования (Экземпляров definition создавать нельзя). definition можно подвергнуть refine (по русски говоря отнаследоваться от него, причем это наследование обычное, а не множественное). И в каждой из refin'ов можно дать новые реализации-по-умолчанию некоторых методов. Object может реализовывать несколько definition, но сам object НЕ ЯВЛЯЕТСЯ единицей наследования, зато экземпляры object-ов создавать можно.
Каждая definition рефайнится по своему дереву (иерархии наследования). Объекты реализуют несколько definition, но сами не участвуют в механизме наследования (т.е. от объекта отнаследоваться нельзя). Таким образом, как я уже раза три повторил, мы получаем все положительные стороны множественного наследования, но в то же время не зарабатываем никаких побочных эффектов.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, WFrag, Вы писали:
WF>> Что мы теряем
СГ>А зато что приобретаем: *.odc — это хранилище сериализованных объектов в (бинарном виде) — так загрузите эти объекты и работайте с самими объектами, а не с текстом как таковым — уровень абстракции резко повышается.
Ты не понимаешь в полном объеме, что мы теряем, я не понимаю, что мы приобретаем конкретно при таком подходе
Мы имеем более высокий уровень абстракции при этом жертвуя более низким. Собственно, против этого пожертвования я и выступаю — все хорошо, пока этот высокий уровень абстракции покрывает наши желания.
Например, в Eclipse я вижу исходники Java в виде дерева пакетов/классов/методов. Это более высокий уровень абстракции, чем текст? Несомненно. Но при этом у меня остается возможность работать и с более низким — например, подсчитать количество слов в программе. Или сравнить два исходника.
Здравствуйте, WFrag, Вы писали:
WF>Например, в Eclipse я вижу исходники Java в виде дерева пакетов/классов/методов. Это более высокий уровень абстракции, чем текст? Несомненно. Но при этом у меня остается возможность работать и с более низким — например, подсчитать количество слов в программе. Или сравнить два исходника.
Так ведь, с объектами это тоже можно, добавил метод подсчета слов и метод сравнения и готово...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, WFrag, Вы писали:
WF>>И еще, объясни, чем эта концепция definition-implementation-object отличается от C++-ых классов?
СГ>Только definition — является единицей наследования (Экземпляров definition создавать нельзя). definition можно подвергнуть refine (по русски говоря отнаследоваться от него, причем это наследование обычное, а не множественное). И в каждой из refin'ов можно дать новые реализации-по-умолчанию некоторых методов. Object может реализовывать несколько definition, но сам object НЕ ЯВЛЯЕТСЯ единицей наследования, зато экземпляры object-ов создавать можно.
СГ>Каждая definition рефайнится по своему дереву (иерархии наследования). Объекты реализуют несколько definition, но сами не участвуют в механизме наследования (т.е. от объекта отнаследоваться нельзя). Таким образом, как я уже раза три повторил, мы получаем все положительные стороны множественного наследования, но в то же время не зарабатываем никаких побочных эффектов.
Ну я где-то так и понял. Получается, концепция C++ по возможностям покрывает концепцию Zonnon-а — и тогда я решительно не вижу в ней чего либо концептуально нового.
Всегда можно сказать:
1. не создавай экземпляры этого класса, пусть там будут только абстрактные методы. Это будет definition.
2. не создавай экземпляры этого класса, пусть он наследуется от definition и реализует некоторые методы. Это будет implementation.
3. не наследуйся от этого класса, но создавай его экземпляры. Это будет object.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так ведь, с объектами это тоже можно, добавил метод подсчета слов и метод сравнения и готово...
Ну я и говорю — изобретаем велосипеды. Вместо того, чтобы на основе одной концепции строить концепции более высокого уровня абстракции, мы отбрасываем все отработанные и отлаженные старые концепции и делаем все заново.
Такими темпами мы на каждый язык/формат будем все средства переписывать.
Вот, например, в чем сила регулярных выражений? В универсальности. Они работают и на конфигах, и на текстах программ, и на документации. Они универсальны. Ты же предлагаешь "до основанья все разрушить".
Здравствуйте, WFrag, Вы писали:
WF>Всегда можно сказать: WF>1. не создавай экземпляры этого класса, пусть там будут только абстрактные методы. Это будет definition. WF>2. не создавай экземпляры этого класса, пусть он наследуется от definition и реализует некоторые методы. Это будет implementation. WF>3. не наследуйся от этого класса, но создавай его экземпляры. Это будет object.
Дык, Zonnon от Си++ много чем отличается: АКТИВНЫЕ ОБЪЕКТЫ, Протокол общения между объектами в форме EBNF, сборка мусора в конце концов....
Здравствуйте, AndrewVK, Вы писали:
AVK>Дело не в этом, дело в том что на изучение шарповских фичек нужно банально больше времени. Например посмотри реализацию событий. В джаве события реализуются при помощи интерфейсов, т.е. если человек уже знает про концепцию интерфейсов, то про события ему вобщем то уже объяснять не нужно. В шарпе же нужно объяснить что такое делегат, потом что такое мультикаст делегат, потом что такое собственно эвент.
Совершенно верно. Причем, что характерно, мы-то с вами понимаем, что это — просто встроенная в язык реализация некоторого специального паттерна, точнее даже семейства взаимосвязанных паттернов. В джаве для достижения того же эффекта все-таки надо чуть больше писать руками.
Все было бы здорово, если бы мы могли вводить все постепенно. Ну типа — вот у нас простой делегат. Он работает вот так-то. Вот ситуация, где надо много подписчиков — ок, можно сделать делегат-диспетчер. Вот ситуация, где нехороший подписчик выкидывает других подписчиков из списка — ок, вот вам разнесенные интерфейсы подписки и итерации.
А вот теперь мы все это обозначаем двумя специальными словами. Увы, первое, что увидят детишки — это именно эти слова. Через полгода они бы сами поняли, в чем их нужность и смысл. А так все выходит задом наперед, т.к. евенты зашиты сразу в библиотеке. AVK>Единственное в чем джава сложнее шарпа, это в концепции вложенных классов. Если в шарпе их по сути просто нет, то в джаве все довольно нетривиально.
Ага. Очень какая-то неожиданная концепция. Хотя, практически, это тоже вшитая в язык реализация некоторого паттерна. В джаве считали, что именно этот паттерн нужен и важен. А делегаты — обойдутся.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
<тут была песнь о DEFINITION>
А в итоге — все тот же самый interface. Только называется по-другому, зато это же кострукция совершенного языка из oberon-family . Тот же бред, что и возмущения по поводу = и ==.
Извините, но вы в этом собираетесь обучать детей????? Умоляю, возьмите в руки Турбо Паскаль/Турбо С и пропагандируйте, чтобы они еще лет десять оставались главным средством обучения. Или учите людей пользоваться коммандной строкой. Прошу и умоляю. НО НЕ ЭТО:
Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что это средства профессинональной разработки. Для того чтобы просто поэкспериментировать можно использовать снипет компиляторы.
Ну, у меня, например, в процессе (профессиональной ) разработки часто возникает потребность эксперимента. С кодом, который писал не я.
Со снипет компиляторами я, к сожалению, не знаком. Не подскажешь, где об этом можно посмотреть поподробнее?
AVK>Я сам больше 6 лет писал на Дельфи. Сложностей освоения джавы я не испытывал.
Андрей, я не имел в виду, что у всех паскалистов будут проблемы. У меня тоже c Джавой проблем не было, и тоже после Delphi Но все же, согласись, знание хотя бы основ С/С++ сильно упрощает обучение. Собственно, именно поэтому и Джава, и Шарп являются наследниками С++
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Так просто, например, рептилоидов поражать. В то время когда это уже было в оберонах MS Word только только делал первые шаги...
Дык в MS Office-то оно вроде как симптаичней выглядит.
Здравствуйте, eugals, Вы писали:
E>Драгдилер, блин E>по $350 за коробан гребёт
Есть такое
E>Смолток хороший язык, что меня в нем смущает, так это доступность реализаций.
E>Под C++ есть куча компиляторов. Есть бесплатный gcc. Есть опенсорсные среды разработки. Море библиотек. E>У шарпа, кроме него самого, есть моно и дотгну. E>У питона есть питон. E>А что со смолтоком? gnusmalltalk, насколько я вижу, ни жив ни мерт E>Есть конечно VW NС, но это дело такое — сегодня они его поддерживают, а завтра бросят... E>Стремно как-то основывать долгоживущие разработки на такой основе. E>Даже если честно купить коробку, всё равно стрёмно. Вдруг они завтра разорятся (продажи-то небольшие, небось).
Черт их знает, говорят, что у них все тип-топ. Ну а как дела обстоят на самом деле, никто не знает. Конечно, риск существует. Но, с другой стороны, этот риск существует всегда при использовании коммерческих продуктов. Та же Delphi. Та же Java, мне кажется — перестанет вдруг Сан ее развивать, и ага. Да что уж говорить, такой риск существует и при покупке сторонних библиотек.
E>А как обстоит дело с совместимостью? E>Насколько реально перевести крупный проект с VW на Dolphin или обратно?
Я не занимался, но мне кажется, что будет довольно сложно. Хотя тут зависит от специфики проекта, конечно. Например, UI придется, видимо переделывать заново, т. к. у Долфина и VW фреймворки построены на различных концепциях. Также, VW намного богаче в плане разработки распределенных приложений, Web-приложений.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Это Вы их в упор не видите. Существенные преимущества неоднократно демонстрировались, главными из которых является то, что Оберон — простой язык (минимальный и достаточный) и высоко-дисциплинирующий программиста. На счет дисциплины — лично мной было указано, на то как высококвалифицированные программисты, но воспитанные на Си-подобных языках, пишут элементарный код циклов используя либо несколько continue либо вспомогательные переменные, хотя и то и другое излишне, так как можно написать тоже самое более просто (дисциплинированно). То есть даже высококвалифицированные специалисты способны блуждать в трех соснах, что было бы не возможно будь они воспитаны на высокодисциплинирующих языках каковыми являются обероны.
Если это шпиля в мой адрес, то это попросту не так.
Уж на чём я по-настоящему воспитан, так это именно на Паскале. Более того, 6 лет это был основной язык разработки.
Хотя руки дотягивались до тучи языков, включая экзотические.
И мой кругозор позволяет без особых усилий писать код любого качества (от стройного до обфусканного) и с любой ведущей парадигмой на любом языке. (Самый мрачный экзерсис, который я когда-то делал — это ООП поверх БД на древнем Клиппере. В качестве курсовика. Эта хреновина даже работала).
Дейкстра не зря говорил про детей, искалеченных бейсиком. Искалечить можно любым языком! Особенно, если догматически впихивать.
Здравствуйте, Сергей Губанов, Вы писали:
WF>> Что мы теряем
СГ>А зато что приобретаем: *.odc — это хранилище сериализованных объектов в (бинарном виде) — так загрузите эти объекты и работайте с самими объектами, а не с текстом как таковым — уровень абстракции резко повышается.
Значит, ты мало трахался с системами контроля версий.
Там даже XML доставляет головную боль (а казалось бы, текстовый...)
А тут — какой-то проприетарный бинарный формат.
В редакторах явки, шарпа, да чего уж там — quick basic 4.5! — есть возможность структурированной работы с исходным кодом, как с совокупностью объектов языка: процедур, классов, метаинформации.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Дык, Zonnon от Си++ много чем отличается: СГ>АКТИВНЫЕ ОБЪЕКТЫ,
А чем оно лучше потоков? СГ>Протокол общения между объектами в форме EBNF,
Ты так и не сказал на кой черт оно надо СГ>сборка мусора в конце концов....
Вот уж нафиг не упало.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
1. Как бы мы не крутили, а исходники все равно читает и редактирует человек. Если исходник — текстовый файл, то неважно, чем он пользуется. Для Винды — это Блокнот (Notepad), Word, MS Word, или например Dreamweaver. У меня был случай, когда редактировал код на PHP в Delphi, потому что под рукой не было другого редактора, сохраняющего отступы при переводе строки.
Что отсюда следует? Легкость в использовании. Пример: Как бы ни были хороши были документы в формате PDF или doc, а для их чтения и редактирования нужен специальзированный вьюер/редактор. С другой стороны, несмотря на то что мне выпала возможность работать с библиотекой Qt, я иногда просматриваю ее исходники в блокноте — и ничего.
2. Текстовый формат = доступность средств для разработки. Любому компилятору, разрабатываему даже энтузиастами-студентами не надо будет дополнительно разбираться в неком проприетарном формате. Вдобавок, не надо будет дополнительно отделять зерна от плевел (код от ресурсов от контролей и форм).
3. Текстовый формат как защита от дурака. Предположим, вы напортачили что-либо в коде. Или нафиг выбило пробки из-за сварщиков на третьем этаже.
В случае текстового формата попорченный файл открывается любым из перечисленных выше средств, находятся ошибки и неправильные символы, все работает. В случае бинарного формата все полетит нафиг. Редактор в жизни не откроет файл, в котором в ключевом месте стоит 1 вместо 0.
История из жизни. Опять Qt, компиляция. Компьютер вылетает нафиг, при перезагрузке файл WinNT.h оказывается попорчен, часть символов заменена контрольными символами < 32 ASCII. Как назло, поблизости не было SDK и пришлось эти самые символы вправлять ручками. 5-10 минут и компиляция пошла дальше. А если бы тот файл был бинарным?
Я думаю, меня здесь поддержат дельфийцы/билдеровцы, которым приходилось ручками править *.dfm файлы когда не переустанавливался какой-нибудь левый компонент.
Опять же, из жизни. Надо было в проекте в Builder'e заменить все компоненты TButton на TCoolButton. Find&Replace в заголовочных файлах и Find&Replace в *.dfm. Вуаля! С бинарниками такое не прокатит.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Ну ты знаток Delphi. exit был еще в Паскале. Про continue могу сомневаться .Может подскажешь в какой версии появился???
VD>В Паскале Exit-а небыло. Тогде у Вирта совсем крышу рвало. Но Exit это завершение приложения и к return-у он отношение не имеет. Так что о чем ты ведешь речь, как всегда понять сложно.
Exit это выход из процедуры. А Continue и Break еще во 2 Delphi были
и солнце б утром не вставало, когда бы не было меня
ПК>Ты говоришь о другой ситуации, а именно о помещении функции sort в класс Array. Дело спорное, т.к. нарушает Open-Closed Principle, но вопрос совсем отдельный.
Я не очень понял, а в чем нарушение? Объясни, пожалуйста
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>И это к чему? То ли скажи название, то ли скажи, какие ты оттудава идеи вынес — в смысле, как надо/не надо описывать языки... ЗХ>А то вишь, хвастается он...
Я к тому, что стоит перед написанием статьи глянуть на книжку. А название не помню . Она, зараза, дома.
О, блин... Дописал и вспомнил. Я же ее по Интернету заказывал.
. Тот же бред, что и возмущения по поводу = и ==.
) разработки часто возникает потребность эксперимента. С кодом, который писал не я. 
Перекуём баги на фичи!
