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

См. на XPath, XSLT, CDuce (особенно на последний). Идей там - полно. Бери любую.

>Nick: AIv
>Полное имя: Anton Ivanov

Тезка или притворяешься?

Спасибо. Не свосем правда то, мне казалось что это ближе к яку или чему то в этом роде... идей то много, не могу сходу сообразить какая более перспективна. ХМЛ тут ИМНО не в дугу, больно общий, фундаментальный подход, а задача у меня вполне примитивная...

Не, я не притворяюсь. А ты? :-)

Вовзращаясь к нашему спору - знал бы ты Лисп, потрудился бы потратить пару дней на его изучение - сейчас бы идеи не искал. Там подобный шаблон работы со структурами данных - очень часто встречается.

А еще про HaXML почитай - там что-то похожее есть. Конечно, не python, зато и не XSLT;-)

> ..наиболее удобным для пользователя образом?

dropdown box

маргинальная ссылка:

http://members.fortunecity.de/dilmah/dl_tokenology.txt

> Есть некий набор объектов, фактически дерево, каждый объект имеет ряд строковых/числовых полей. Необходимо придумать неикй механизм, позволяющий гибко (и удобно) задавать синонимы для объектов, то есть что бы после пропускания через этот механизм нек-е объекты заменялись на другие. Вопрос в том как это сделать наиболее удобным для пользователя образом?

Один из нас -- дурак, определенно.

Кто такие "объекты"? Их надо друг на друга заменять? А механизм -- стохастический?

И столько ответившего народу...

> Один из нас -- дурак, определенно.

Наверное, я -- не хочется о людях думать плохо...

Мдя... ладно, надо конкретизировать видимо, обощать буду потом сам:-)

Есть пользовательское (разаработанное пользователем) приложение, состоящее из нескольких модулей (файлов с исходным кодом). Модули загнаны под CVS. Есть файло (таблица), в котором записаны версии модулей, репозитоии даты сосздания и пр. А так же кто из модулей от кого "зависит" - т.е. кто кого подцепляет (факт дерево). При обратной сериализации объекта запикленного этим приложением поднимаются модули соотвествующих версий. Но у пользователя регулярно возникает потребность обновить версии каких то модулей. То есть он где то прописывает что для такого модуля (возможно в таком то объекте) вместо такой то версии нуно использовать такую то. Или для такого репозитория такой то. Или для такой то даты такой то. И т.п. Сложность еще в том состоит что модули друг от друга зависят, и в приципе эта зависимость тоже может быть критерием по изменению версии (или еще чего), а в новой версии кстати и зависмость может быть другой....

Беда не в отсутвии идей (на это не жалуюсь:-)) - беда в том что их как раз слишком много, и не понятно что будет наиболее пральными (удобным) видимо придется реализовать что нить самое примитивное, а потом по мере надобности прикручивать новые фичи (и баги:-)))

Про ХМЛ - нету у меня внутреннего ощущения что это то... то есть понятно что задачу моно свести у ХМЛ, и потом в ее терминах оперировать... но получается шило на мыло.

Спасибо большое за ответы.

Ну так это же просто граф. Как представлять графы, и как определить все основные операции над графами - давно известно. Кури теорию, однако.

Ептить.... да нету проблемы в том как это представить и т.д. - есть проблема в том как это сделать удобно в использовании!

Про конфликт м-ду мощностью/уровнем слышали? Все что есть из такого фундаментального весьма мощно, позволяет делать все что угодно... т.е. любая конкретная операция выливается в некоторый геморрой.

> Про конфликт м-ду мощностью/уровнем слышали? Все что есть из такого фундаментального весьма мощно, позволяет делать все что угодно... т.е. любая конкретная операция выливается в некоторый геморрой.

ну так твоя задача -- это задача которую решает любой package manager с зависимостями..

А тебе уже советовали использовать языки, которые позволяют выбрать любую нужную тебе степень абстракции, или конкретизировать до нужного уровня любую абстракцию. Ты же в свой C++ упёрся, и теперь мучаешься...

>А тебе уже советовали использовать языки, которые позволяют выбрать любую нужную тебе степень абстракции, или конкретизировать до нужного уровня любую абстракцию. Ты же в свой C++ упёрся, и теперь мучаешься...

В данном случае речь я пишу на питоне. Про конкретизацию и абстракцию - см. выше. Я ж не для себя дела.ю а для тупых кодеров, все должно быть понятно... они и слов то таких как абстракция не знают:-)

Тем более - раз для тупых, то надо сделать для них наиболее простой и понятный язык для работы с этими графами, а не заставлять бедненьких приспособить Питон туда, куда он никак не подходит.

Епрст.... во первых для пользователя графовость задачи тут если будеьт стрелять, то весьма редко ИМНО.

Во вторых пигон для этой задачи подходит прекрасно, не надо ля-ля:-) Если у Вас не хватает фантазии сообразит как его тут применить, то это чиста Ваши сложности а не питона:-)))

без обид........

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

Э... в приницпе да, именно об этом и речь. Токо задача не в том как эти зависимости раскрутить (это тривиально), задача втом какой функционал предоставить юзеру для эффективного изменения этих зависмостей... то чт оесть в CVS напр ИМНО довольно скромно, хочеться большего...

А так обычно pm -ы как мне казалось просто зависимости поднимают, и их изменение (ручная перенастройка) явление доволлььно редкое? Или я не прав?

Что такое domain specific languages мсье не понимает. Так и запишем.