Здравствуйте, lomeo, Вы писали:

.>>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.
L>Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
Это можно поймать инспекциями в IDEA или на build-сервере.

Здравствуйте, Cyberax, Вы писали:

.>>>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.
L>>Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
C>Это можно поймать инспекциями в IDEA или на build-сервере.

Я там выделил, о чём мы говорим.

Здравствуйте, lomeo, Вы писали:

.>>>>Ничего подобного. Если идеи нет или она что-то не умеет — меняешь файлы как нравится. Она ничего "своего" не создаёт, обыкновенные исходники. Файлы проектов идеи даже не обязательно класть в систему контроля версий.
L>>>Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь название класса стиля и привет! В хтмл он не отобразится.
C>>Это можно поймать инспекциями в IDEA или на build-сервере.
L>Я там выделил, о чём мы говорим.
Ну и? Если IDEA нет, то говорить об IDEA как-то особо смысла не имеет.

Я говорю про то, что IDEA прекрасно работает с внешними изменениями.

lomeo wrote:

> .>Так объясняю же, нечего генерировать-то. Просто это разная информация,
> но связанная. Одна информация описывает структуру объекта (поля и их
> типы), а другая — как этот объект взаимодействует с субд.
> Ну, я генерировал. Плюс ещё и морду. Из одного места всё.
Может тебе повезло с задачей, что всё, от структуры БД до ГУИ можно сгенерировать по одному описанию.

> Это пример. В качестве инструмента для избавления от дублирования очень
> даже ничего.
Что плохо в аннотациях — в одном месте куча разных вещей.

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

> Тогда мы теряем в синхронизации! Поменяешь ты без IDEA где нибудь
> название класса стиля и привет! В хтмл он не отобразится.
Не понял. Синхронизации чего с чем? Если ты что-то поменял вручную и перестало работать, то значит руки кривые. Спрашивается накой вручную было менять?

Кстати, можно будет запустить инспекции в ИДЕЕ и проверить, что всё "синхронизовано".

Здравствуйте, Cyberax, Вы писали:

C>Ну и? Если IDEA нет, то говорить об IDEA как-то особо смысла не имеет.

Ты отвечаешь на пункт о привязке к IDEA.

C>Я говорю про то, что IDEA прекрасно работает с внешними изменениями.

Согласен.

Здравствуйте, ., Вы писали:

.>Может тебе повезло с задачей, что всё, от структуры БД до ГУИ можно сгенерировать по одному описанию.

Не всё, само собой. Но то, что можно генерировать я предпочитаю генерировать. А так — да, возможно, мои задачи просто хорошо ложатся на генерацию. У меня ведь не рокет сайенс.

.>Что плохо в аннотациях — в одном месте куча разных вещей.

Не спорю. Я говорил о том, что в них хорошего.

.>Не понял. Синхронизации чего с чем? Если ты что-то поменял вручную и перестало работать, то значит руки кривые. Спрашивается накой вручную было менять?

Значит, привязка к IDEA есть.

Я о чём вообще толкую — мне кажется, что если есть зависимости, то их можно отразить в коде, а можно в IDEA. Я предпочитаю код. Вот и всё. Спорить вроде как не о чем?

Здравствуйте, ., Вы писали:

А вообще прикольно как мы от темы оторвались!

lomeo wrote:

> Значит, привязка к IDEA есть.
Что ты под привязкой понимаешь?

> Я о чём вообще толкую — мне кажется, что если есть зависимости, то их
> можно отразить в коде, а можно в IDEA. Я предпочитаю код. Вот и всё.
> Спорить вроде как не о чем?
Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.

lomeo wrote:

> А вообще прикольно как мы от темы оторвались!
философия...

Здравствуйте, Cyberax, Вы писали:

C>>>Чего ты тут будешь генерировать?
VD>>SQL?
C>Это далеко не всегда возможно.

В каких? Использование DBF?

VD>>Лично мне нравится идея когда БД описывается специальным ДСЛ-ем, а уже ее структура генерируется и изменяется с помощью универсального кода который читает это описание, сравнивает его с метаинформацией взятой из БД и модифицирует БД так чтобы она соответствовала исходному описанию.
C>Это противоречит использованию легковесных mapper'ов, за которые тут не так давно были битвы

С чего бы это?
И вообще, откуда эти догмы?

C>Вариант, на самом деле, интересный. Я примерно сейчас его и использую — DSLем являются файлы mapping'а Hibernate.

Выражаю тебе свои соболезнования. Хуже ДСЛ чем недоязык основанный на ХМЛ-е придумать трудно.
Я бы предпочел более высокоуровеное описание.

C>Но дальше начинаются интересные вопросы — если мы используем код с аннотациями

Это не обязательно должно быть кодом на универсальном языке. Это может быть встроенным или внешним ДСЛ-ем являющимся высокоуровневым описанием требуемых сущностей.

C>в качестве единственного источника информации, то у нас в скомпилированном коде будет информация о таблицах и запросах хранится. А если мы хотим эту сборку отдать внешним клиентам? Тогда надо будет как-то вытащить информацию из неё.

Задача сформулирована как-то мутно. Попробую ответить, но не уверен, что угадаю все недостказанное.
Сборка умеет работать с конкретной структурой БД. В ней ведь код который рассчитан на обработку конкретных данных. Сборка сама модицицирует не подходящую БД или создаст новую... если что. Так что отдавай. Проблем не будет.

C>Или мы, может быть, хотим одну модель данных использовать для нескольких mapping'ов. Тоже некрасиво получается.

А зафиг мне какие-то маперы? У нас есть метаописание, набор поддерживаемых СУБД и встроенный в сборку код который позволяет работать с поддерживаемыми СУБД. Вот последний — это есть высокоинтеллектуальное решени которое требует мощьных средств разработки. Но в их число я бы включил хороший язык с поддержкой метапрограммирования, а не внешний мапер и уж тем более не гибернэйт.

Здравствуйте, VladD2, Вы писали:

VD>>>SQL?
C>>Это далеко не всегда возможно.
VD>В каких? Использование DBF?
В том числе. Или необходимость разных шаманств со схемой (типа назначения tablespace'ов и прочего тюнинга).

C>>Это противоречит использованию легковесных mapper'ов, за которые тут не так давно были битвы
VD>С чего бы это?
VD>И вообще, откуда эти догмы?
Так как нам надо будет

C>>Вариант, на самом деле, интересный. Я примерно сейчас его и использую — DSLем являются файлы mapping'а Hibernate.
VD>Выражаю тебе свои соболезнования. Хуже ДСЛ чем недоязык основанный на ХМЛ-е придумать трудно.
VD>Я бы предпочел более высокоуровеное описание.
XML — это просто (ну не самый удачный, да) способ записи дерева, которое может использоваться для чего угодно. К уровню описания он не имеет особого отношения.

C>>Но дальше начинаются интересные вопросы — если мы используем код с аннотациями
VD>Это не обязательно должно быть кодом на универсальном языке. Это может быть встроенным или внешним ДСЛ-ем являющимся высокоуровневым описанием требуемых сущностей.
Это всё понятно.

C>>в качестве единственного источника информации, то у нас в скомпилированном коде будет информация о таблицах и запросах хранится. А если мы хотим эту сборку отдать внешним клиентам? Тогда надо будет как-то вытащить информацию из неё.
VD>Задача сформулирована как-то мутно. Попробую ответить, но не уверен, что угадаю все недостказанное.
VD>Сборка умеет работать с конкретной структурой БД. В ней ведь код который рассчитан на обработку конкретных данных. Сборка сама модицицирует не подходящую БД или создаст новую... если что. Так что отдавай. Проблем не будет.
Нет, у меня другая проблема. Я описываю структуру базы в виде entity-классов:

class User
{
    public Set<Role> roles;
//...
}
class Role
{
    public Set<Role> users;
//...
}

Эти entity-классы идут в клиентскую библиотеку, которая распространяется заказчикам.

А на сервере используется mapping в отдельных файлах для её отображения на БД и XML:

<class name="User" table="system_user">
        <set name="roles" cascade="save-update">
            <cache usage="read-write"/>
            <key column="parent_user"/>
            <many-to-many class="Role" column="parent_role"/>
        </set>
</class>
<class name="Role" table="system_role">
        <set name="users" cascade="save-update">
            <cache usage="read-write"/>
            <key column="parent_role"/>
            <many-to-many class="User" column="parent_user"/>
        </set>
</class>

Это отображение отделено от самих entity и содержит данные, которые никакого отношения к самим сущностям не имеют. Скажем, режимы кэширования или имена таблиц. Мне их отдавать заказчикам совсем не хочется, например.

А ещё может быть отдельный mapping на XML или настройки для объектной БД. А ещё для отдельных БД может потребоваться дополнительные шаманства в mapping'е.

Как такое можно красиво сделать? Пока только приходит идея дважды инстанцировать макросы — один раз в клиентской библиотеке, а другой раз в серверной. Некрасиво.

C>>Или мы, может быть, хотим одну модель данных использовать для нескольких mapping'ов. Тоже некрасиво получается.
VD>А зафиг мне какие-то маперы? У нас есть метаописание, набор поддерживаемых СУБД и встроенный в сборку код который позволяет работать с поддерживаемыми СУБД. Вот последний — это есть высокоинтеллектуальное решени которое требует мощьных средств разработки. Но в их число я бы включил хороший язык с поддержкой метапрограммирования, а не внешний мапер и уж тем более не гибернэйт.
Тем не менее, Hibernate + IDEA уже решают эту проблему более чем удовлетворительно.

Здравствуйте, lomeo, Вы писали:


L>Самое сильное — do-нотация

В ФП-языке самое сильное — это императивные блоки?

T>>>Почему State monad уродство? Твоё личное предпочтение?
V>>Обычное lvalue.

L>Потому что на императивном языке это примитивная операция?

Дык она примитивная по фундаментальным причинам, по крайней мере до тех, пока компьютера на регистрах выполнены.

L>О, это сделано для удобства. Не надо писать map :: forall a b. (a -> b) -> [a] -> [b], достаточно просто (a -> b) -> [a] -> [b] и то, что a,b — параметры типа, а не конкретные типы определится по регистру. Что касается конструкторов против функций — то верхний регистр — это что-то вроде new в С#: x = Foo 42 против x = foo 42.

Полноценно обсуждать эту тему не готов, но согласно ИМХО — экономия на спичках.

Здравствуйте, ., Вы писали:

>> Значит, привязка к IDEA есть.
.>Что ты под привязкой понимаешь?

То, что теперь тебе придётся пользоваться IDEA.

>> Я о чём вообще толкую — мне кажется, что если есть зависимости, то их
>> можно отразить в коде, а можно в IDEA. Я предпочитаю код. Вот и всё.
>> Спорить вроде как не о чем?
.>Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.

Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.

Здравствуйте, lomeo, Вы писали:

.>>Что ты под привязкой понимаешь?
L>То, что теперь тебе придётся пользоваться IDEA.
Необязательно. Можешь пользоваться любой другой IDE, но тогда не будет IDEAвских фич.

.>>Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.
L>Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.
Как ты отразишь зависимости, если язык этого не позволяет?

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, thesz, Вы писали:

T>>>>Как они с поддержкой программ для Wall Street справляются?..
KP>>>А он вообще нужен? Лично для меня, необходимость в отладчике очч спорный момент. Если он есть, это безусловно хорошо, но если его нет, то логов всегда достаточно. А если еще и библиотека логирования хорошая, то отладчик скорее будет лишним

T>>Сколько людей, столько и мнений

Автор: eao197
Дата: 06.03.09

.

T>>Моё, кстати, примерно такое же, как у тебя.

KP>На мой взгляд тут довольно просто все. Если человек писал под большое количество платформ, то он наверняка хорошо умеет работать с логами, в особенности если приходилось писать поп встроенные/мобильные платформы. Если же основной опыт это Java, .NET и только под Винду.. Ну что ждать от такого конеченого человека

а к чему эти наезды на джавистов? у них есть log4j и распарсывать результат им приходится

Здравствуйте, vdimas, Вы писали:

L>>Самое сильное — do-нотация :))
V>В ФП-языке самое сильное — это императивные блоки?

Это шутка?

L>>О, это сделано для удобства. Не надо писать map :: forall a b. (a -> b) -> [a] -> [b], достаточно просто (a -> b) -> [a] -> [b] и то, что a,b — параметры типа, а не конкретные типы определится по регистру. Что касается конструкторов против функций — то верхний регистр — это что-то вроде new в С#: x = Foo 42 против x = foo 42.

V>Полноценно обсуждать эту тему не готов, но согласно ИМХО — экономия на спичках.

Ну как же спички. Foo — такая же функция, только создаёт некое значение. Если мы будем писать new Foo, то это уже далеко не ФВП. Бритва Оккама и всё такое.

Здравствуйте, Cyberax, Вы писали:

.>>>Что значит отобразить зависимость в IDEA? IDEA это не яп, и уж тем более не dsl, это такой продвинутый текстовый редактор, который понимает семантику редактируемых файлов (и не только файлов) и распознаёт взаимосвязи между ними.
L>>Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.
C>Как ты отразишь зависимости, если язык этого не позволяет?

Генерацией с языка, который это позволяет.

Здравствуйте, lomeo, Вы писали:

L>>>Отразить, а не отобразить. То, что имя класса css в атрибуте class и в css файле связаны.
C>>Как ты отразишь зависимости, если язык этого не позволяет?
L>Генерацией с языка, который это позволяет.
Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?

Здравствуйте, Cyberax, Вы писали:

L>>Генерацией с языка, который это позволяет.
C>Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?

Зачем дизайнеру трогать результирующий HTML или CSS??

lomeo wrote:

> Зачем дизайнеру трогать *результирующий* HTML или CSS??
А что будет трогать дизайнер?