Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вот объясни мне, почему ты начинаешь видеть в этом кашу? Почему код с сишным синтаксисом в кашу не превращается? Да, в ХМЛ есть небольшой синтаксический оверхед. В бейсике тоже есть, ты тоже в его коде видишь кашу?
Как тебе сказать? Дело в том, что ХМЛ в 10, а то и более раз более пушист нежели конкретный язык. При некотором объеме он бдет сливаться и выглядить как набор скобочек.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Надеюсь, объяснил доходчиво...
Обращения к классам можно и маршаллить, соотвественно будешь спокойно отслеживать все вызовы в т.ч. и конструктора и фабрика у тебя может прекрасно работать через new.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Как тебе сказать? Дело в том, что ХМЛ в 10, а то и более раз более пушист нежели конкретный язык. При некотором объеме он бдет сливаться и выглядить как набор скобочек.
Считаю коммент про 10 раз провокацией
Из всего синтаксического оверхеда там только небходимость указания полного квалиф. имени элемента при его закрытии. Ну возможно префиксирование каждого элемента по пространству имен. Все. Если описываешь на ХМЛ скажем какие-то бизнес-объекты или там АСТ отличие даже по синтаксису от шарпа или бейсика будет весьма декоративным.
В общем предлагаю создать тему XSLT vs. Nemerle и серьезно заняться обсуждением этого вопроса
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[26]: Снова о Nemerle или профанация не пройдет :)
VD>Причем ошибиться нигде нельзя! Если ты впишешь неверное имя переменной в текст, то тебя остановит компилятор! А в C# ты рискушь получить ошибку во время выполнения (неверный форма или еще что).
Не, Влад, так — не круто. Приложения должны поддаваться локализации; а это означает переменный порядок "вставленных" слов во фразе. Неслучайно в Delphi/Builder был применен вариант сишного формата, в котором можно было указывать аргументы не в порядке следования. И неслучайно в дотнете единственный необходимый параметр формата — это номер аргумента.
С учетом того, что ToString() вморожено прямо в object, возможные ошибки сводятся к недостаточному количеству аргументов либо ссылок на них. Если удастся встроить их проверку, то будет круто.
Кстати, я вот еще думал в свое время над синтаксисом типа такого:
Тут гораздо труднее ошибиться. Но представления не имею, как это можно проверить в компайл-тайме (особенно с учетом вышесказанного насчет локализации, т.е. выносе строковых констант за пределы кода).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Vermicious Knid, Вы писали:
E>>Только вот о вкусах, конечно, можно спорить, но мне этот код красивым не показался. В особенности <[ и ]> -- путаюсь к чему что относится.
VK>Ну во-первых нет "правильной" подсветки синтаксиса.
+1
Но все равно код уж сильно на Perl-овку смахивает. Это и не нравится.
C++ шаблоны для меня так же не являются верхом изящества. Поэтому от трехэтажных шаблонов в C++ меня начинает отворачивать уже даже по эстетическим соображениям.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Oyster, Вы писали:
O>Да ты просто задокументируй сам макрос — делов то. Всё равно дока будет автоматом сгенерирована и полезной информации в ней будет мало. Мне, кстати, генерация в compile-time гораздо больше нравится — нет никакой возни с поддержкой кода, сгенерированного в precompile-time (класть/не класть в VSS/CVS/SVN, как следить за тем, чтобы никто ничего не модифицировал и т.д.).
Я придерживаюсь мнения, что результаты генерации вообще в VCS попадать не должны. Там должны быть только исходники, из которых производится генерация. Например, для yacc-а под контроль версий нужно укладывать .y-файлы, но вот полученные из них .c-файлы помещать под контроль версий смысла нет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, WinniePoh, Вы писали:
VD>> Так вот макросы Нэмерла избавлены от оных недостатков. И они просто являются мощным инструментом к злу не относящемуся.
WP> Увы, не избавленны. Только что проверки ради создал работающую, но абсолютно нечитабельную и отладке не подлежащую макру. Показать?
Да.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>А можно ли как-то в генерируемом классе использовать другие макросы?
Макросы внутри кода функций однозначно использовать можно. Насчет совсем других макросов я не знаю, надо поинтересоваться на досуге.
VD>Ведь реализация свойств по полям уже реализована в макросе Nemerle.Utility.Accessor. А реализация конструктора для всех полей в макросе Record.
Record это только для публичных полей(т.е. строго говоря для описания конструкторов структур). Accessor у меня использовать не получилось. Он его почему-то не опознает. Возможно это из-за того, что он обычно выполняется на более раннем этапе компиляции, или по другим причинам. Нужно спросить разработчиков языка.
VD>Так что если бы эти макросы можно было бы задействовать, то осталось бы только сформировать класс и список полей. Если при этом вынести в универсальный модуль такую байду как выскребание описания свойств, то код такого макроса был бы совсем небольшим и весьма понятным.
В универсальный модуль можно вынести. Есть еще пара мест где код можно упростить. Собственно местами я сделал лишнее и не заметил как можно сократить составление списка свойств. Если бы Accessor работал, то код выглядел бы так:
А вообще-то и неупрощенный код это всего полсотни строчек. И учитывая, что он делает работу сразу трех макросов это очень хороший результат. Но насчет выноса частоиспользуемых вещей в универсальный модуль ты пожалуй прав. Я сам думал над этим неоднократно.
Re[16]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Обращения к классам можно и маршаллить, соотвественно будешь спокойно отслеживать все вызовы в т.ч. и конструктора и фабрика у тебя может прекрасно работать через new.
Отлично. А о перфомансе ты не подумал?
Re[17]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, VladD2, Вы писали:
VD>Привел отрывок какой-то хрени
Влад, у тебя есть, что сказать или как обычно? Или может ты таким хитрым способом хочеш сказать, что тоже думаеш, что сопоставлением с образцом в Nemerle нужно сравнивать именно с if/switch в C#?
VD> и делашь далеко идущие выводы.
Вывод был только один — сравнение не корректно, соответсвенно выводов из него делать нельзя. Вот такой я вывел "далекоидущий" вывод.
VD> Человек привел аналогичный код. Ты же хрен знает что.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здесь мне кажется есть другой момент — если-таки продолжать гнуть линию партии — как раз касающийся этой самой "тысячи" макросов. Так как появится возможность оформлять функционал в виде макросов, и ей, скажем, начнут активно пользоваться, то перед изучением новых библиотек для сотрудников надо будет проводить специальные психо-трейнинги и убрать на это время из офиса все колюще-режущие предметы. Вот представь себе библиотеку для работы, скажем, с серийным портом всю написанную на макросах. По суть вместо некого КОМ-порт АПИ у нас будет специальный язык под это дело, причем еще не факт что удачного спроектированный. И таких библиотек на большом проекте могут быть десятки. Причем в 90 случаях из 100 эти макросы не будут предлагать ничего по сравнению с обычным АПИ кроме другой формы записи.
+1
Можно еще и другой аспект затронуть -- отладка кода, который получился в результате использования макросов. Не кода макросов, а прикладного кода, в котором макросы будут использоваться. Я думаю, что не так уж и редко будут возникать ситуации, когда захочется посмотреть, а что же там внутри с моими параметрами происходит, почему же не работает ни хрена? Многие здесь, я думаю, пользуются пошаговой отладкой. Вот как с ней быть?
Я хоть отладчиками и не пользуюсь практически (пошаговой отладкой так точно), но в некоторых случаях приходится код отладочными печатями разбавлять. Придется, получается отладочные печати в тела макросов засовывать (всегда ли исходники макросов будут доступны)?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Снова о Nemerle или профанация не пройдет :)
Здравствуйте, Vermicious Knid, Вы писали:
VK>Record это только для публичных полей(т.е. строго говоря для описания конструкторов структур). Accessor у меня использовать не получилось. Он его почему-то не опознает. Возможно это из-за того, что он обычно выполняется на более раннем этапе компиляции, или по другим причинам. Нужно спросить разработчиков языка.
Может быть, потому, что поле ещё не добавлено в класс? Т.е. в AST есть объявление поля, но перед тем, как отработает Define, поля ещё не будет у класса. Это я на имя класса макроса посмотрел: Accessor_field_postscanMacro.
Получается, что макросы, модифицирующие тип, вообще не получится использовать при объявлении типа. Хотя звучит это по меньшей мене странно на фоне того, что обычные макросы можно спокойно использовать в теле функции. Странно, но тем не менее немного рационально.