[Devel-conf] описание структуры бакенда на примере пользователей (was alterator backends and XML Schema)

[Peter V. Saveliev]

В сообщении от Wednesday 17 October 2007 13:12:57 Alexander Bokovoy 
написал(а):
> Peter V. Saveliev пишет:
> >> 	uint32	users_new(
> >> 		[in,ref]	string *name,
> >> 		[out,ref]	user_account *account
> >> 	);
> >> }
> >
> > слова про xml и андроидов беру назад... ;)
>
> А что именно? Плохо, хорошо, что? :-)
>
> Код выше человек читает нормально. Следом за ним читает компилятор и
> генерирует код на определенном языке, какой заложен -- у нас C, в
> Microsoft -- C/C++/C#, в jCIFS -- Java и так далее. Написать расширение
> для pidl (Samba4), чтобы генерировался код для scheme/python/etc --
> особых проблем нет вообще.
<skip />

Ключевой момент, который я не понимаю -- это уверенность в том, что код 
_нужно_ генерировать. Причём в такой манере. Я не говорю, что она плохая, мне 
просто кажется, что в данном случае это может быть слегка не в кассу.

Посмотрите на это с точки зрения разработчика, который хочет написать _один_ 
_простой_ модуль к альтератору или неважно к чему. Но модуль, реализующий 
дерево команд. Скажем, из трёх узлов. Для него чем меньше телодвижений нужно 
совершить, тем лучше. Что мы имеем и что нам нужно:

У нас есть:

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

То есть, для описания древовидной структуры он может:

 * описать каждый узел в своём файле, файлы организовать в иерархическую 
структуру на ФС
 * описать все узлы в одном файле

У меня возможны оба метода, но в connexion использется не шелл, а python, где 
описание вложенных классов -- вещь тривиальная. Однако, сферический 
разработчик требует шелл, и нехочет писать несколько файлов (не понимаю, 
почему, но Стас меня заверил в этом). И тогда, 

Что нам нужно:

 * возможность написать "плоский" файл и карту, которая методы плоского файла 
будет проставлять в соответствие стандартным методам узлов, как это принято в 
движке.

Если по пути будет генериться код-скелетон для шелл-модуля -- хорошо, но он 
должен получаться очень просто. А то, что я увидел выше -- само по себе код, 
причём не самый простой (для такого тривиального случая).

Если бы я собрался писать для альтератора и увидел бы этот пример -- я бы 
крепко призадумался. Я не говорю, что IDL плохо. Просто меня это бы испугало: 
невозможно знать всё, а этот пример требует явных усилий по изучению чего-то 
не очень простого, что мне пока нигде не нужно было и вряд ли где-то ещё 
пригодится. Учитывая, что последнее время я начал достигать порога насыщения, 
для меня это потенциально тяжёлая ситуация.
-- 
Peter V. Saveliev