concolor

QUOTE (u2227 @ Oct 20 2007, 19:04) QUOTE (concolor @ Oct 20 2007, 16:47) .....если рассмотреть этот класс как часть модуля со своим интерфейсом, то в этом случае этот класс как реализация интерфейса уже не абсолютно защищен, т.к. метод getf() может быть вызван помимо интерфейса без изменения исходников реализации. То есть надо скрыть и сами классы входящие в модуль? достаточно все методы и атрибуты классов в модуле объявить закрытыми, а класс интерфейса - другом класса реализации. После этого, несмотря на то, что формально классы реализации будут доступны извне, сделать ничего с их помощью без привлечения класса интерфейса будет невозможно. Даже просто создать объект такого класса - конструкторы же тоже будут закрытыми. Поэтому сами классы скрывать смысла не имеет.

QUOTE (u2227 @ Oct 20 2007, 17:23) Я кстати готов поставить под сомнение понятие "абсолютной защиты" вообще. Но в данном контексте готов его принять для простоты. Я не понимаю, что значит "поставить под сомнение понятие". В данном случае я сделал некоторое определение, а определение по своей природе аксиоматично - оно само по себе не истинно и не ложно, оно есть и все. Другой вопрос - насколько полезно то или иное определение. С моей точки зрения понятие "абсолютной защиты" полезно, поскольку точно определяет некое хорошее свойство "закрытости" програмного модуля как пары интерфейс-множество реализаций. Более того, примеры програмных модулей удовлетворяющих этому определению существуют (собственно то, что изложено в первом посте), равно как и примеры не удовлетворяющие. Это также служит подтверждением полезности понятия, т.к. оно не тривиально. P.S. oops, я несколько откорректировал понятие модуля, которые использовал в этом посте. А именно, под модулем следует понимать пару не интерфейс-реализация, а пару интерфейс - множество реализаций. P.P.S. общее определение модуля по википедии: QUOTE A module is a self-contained component of a system, which has a well-defined interface to the other components; something is modular if it includes or uses modules which can be interchanged as units without disassembly of the module. Design, manufacture, repair, etc. of the modules may be complex, but this is not relevant; once the module exists, it can easily be connected to or disconnected from the system. Определение модуля програмной системы: QUOTE Modules provide a separation between interface and implementation. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are visible to other modules. The implementation contains the working code that corresponds to the elements declared in the interface.

QUOTE (u2227 @ Oct 20 2007, 17:16) Вот такой пример, чем не устраивает отца русской демократии? Разве f плохо защищена? вопрос в том, что понимать под "хорошо/плохо" защищенными функциями и в каком контексте. Выше я строго определил понятие "абсолютной защиты" по отношению к паре интерфейс-реализация, а не вообще само по себе. Если рассмотреть класс как самостоятельную сущность и открытые методы класса как его интерфейс - то да, атрибут f (как и все закрытые атрибуты и методы) абсолютно защищен относительно этой пары. Но если рассмотреть этот класс как часть модуля со своим интерфейсом, то в этом случае этот класс как реализация интерфейса уже не абсолютно защищен, т.к. метод getf() может быть вызван помимо интерфейса без изменения исходников реализации.

QUOTE (Nox Metus @ Oct 20 2007, 15:42) QUOTE (concolor @ Oct 20 2007, 15:32)А именно, в парсере/прувере/трансляторе формальной математике есть несколько очевидных крупномасштабных структурных единиц типа monostate: -- парсер исходного языка - статический, ибо несколько экземпляров парсеров make no sense. Создается сразу при начале работы. -- внутри парсера подсистема - набор таблиц идентификаторов. Каждая таблица - в единственном экземпляре, создается сразу при начале работы. -- также внутри парсера - лексер, тоже monostate класс. -- модуль - хранилище уже доказанных теорем и аксиом. Очевидно, тоже monostate объект, который внутри себя имеет некоторую более мелкомасштабную структуру статических классов. -- подсистема вывода - ответственна за вывод результатов доказательств и трансляции в target. Тоже monostate со внутренней структурой.Опять много букв и ничего конкретно относящегося к постановке задачи. Из всего перечисленного никак не проглядывает «абстрактный интерфейс к monospace» и как он будет использоваться. QUOTE (concolor @ Oct 20 2007, 15:32)А теперь вопрос: в чем сферичность, где конь и почему в вакууме ??Это идиома. Означает, что вы изобретаете нечто, применение чего и практическая ценность вызывает определенные сомнения. Пока вы мои сомнения не развеяли. Попытайтесь еще раз, пока я окончательно не потерял интерес. Никак не могу понять, что вы имеете в виду под постановкой задачи. 1) конкретные проблемы дизайна конкретной програмной системы? 2) описание некоей ситуации, возможной при дизайне програмной системы и набор требований (с мотивацией), которые нужно выполнить ? Если второе, то, с моей точки зрения, я очень подробно это расписал выше. Если первое, то мне остается выложить исходники своего проекта и продемонстрировать конкретные классы, к которым я хочу определить интерфейс. Боюсь что это будет весьма непоказательно, поскольку система в процессе рефакторинга, там много мусора и несогласованностей и ошметков старого дизайна. Я сконяюсь к тому, что просто буду методично использовать расмотренную выше конструкцию и посмотрю, к чему это приведет. Когда система будет работоспособна, выложу в эту ветку исходники, ссылки на конкретные классы, интерфейсы к ним и т.д.

QUOTE QUOTE (concolor @ Oct 20 2007, 14:29)Насчет отличия от набора функций в пространстве имен - да, действительно это очень похожие на monostate класс. Но, к сожалению, от пространства имен нельзя наследоватьЗачем наследовать от класса у которого только статические методы? Вы в курсе зачем вообще наследование нужно? В случае статического интерфейса - согласен, наследовать не нужно (кстати у меня в первом примере и нет этого наследования). А вот во втором примере - когда я определил невиртуальный интерфейс уже для произвольного класса - без наследования не обойтись. Поскольку предложенный мной механизм унифицирует оба эти подхода (они почти не различаются), то мне очевидно, что это лучшее решение, чем раздельное для обоих случаев, использущее пространства имен или ещё что либо. QUOTE QUOTE (concolor @ Oct 20 2007, 14:29)и нельзя объявлять функции в пространстве имен закрытыми - это можно делать только с классами.Закрытыми от чего? Вы можете часть функций продекларировать и определить в пространстве имен не в загловочном файле, а в файле реализации. Эти функции будут с успехом закрыты от пользователя, который будет видеть только ваш интерфейс, объявленный в заголовочном файле. Ок. Попробую аргументировать следующим образом. Определение интерфейс абсолютно защищает реализацию, если для того, чтобы вызвать какой-либо метод реализации или обратиться к атрибуту класса реализации минуя интерфейс, необходимо модифицировать исходники реализаци. Утверждение 1 Предложенные мной интерфейсы допускают возможность абсолютной защиты реализации. Доказательство. Все методы и атрибуты классов реализации объявим закрытыми, если один из методов требует доступа к другому - объявляем его другом, а интерфейс объявлем другом всех классов реализации. Утверждение 2 Если в реализации классов есть хоть один не закрытый метод или атрибут, или в каком-либо пространстве имен в реализации есть хоть одна функция, то не существует интерфейса для этой реализации, который бы ее абсолютно защищал. Доказательство. Есть возможность обратиться к методу класса, атрибута или вызвать функцию без изменения исходников реализации. Пространство имен не спасает - можно обратиться к функции в этом пространстве имен не меняя исходников. Сентенция: Это хорошо, когда интерфейс абсолютно защищает реализацию, так как логически исключает возможность несанкционированного доступа к ней. Вывод: Рассмотренные мною конструкции интерфейсов хороши, поскольку делают возможной абсолютную защиту реализаци.

QUOTE (Nox Metus @ Oct 20 2007, 14:49) QUOTE (concolor @ Oct 20 2007, 13:15) г) позволяет легко менять различные реализации для данного интерфейса.Я не знаю что значит «легко». А вы? Легко по сравнению с чем? Вы пишите очень много буков, при этом так и не определились (по крайней мере здесь на форуме) с вашим вариантом использования того, что городите. Задайте себе вопрос: как и зачем это будет использоваться. Именно из наиболее точного и конкретного представления этого должно строиться решение. Пока у меня сложилось впечатление, что вы стремитесь сделать наоборот: поместить сферического коня в вакуум, а потом посмотреть зачем он нужен. QUOTE QUOTE (concolor @ Oct 20 2007, 13:15)2) зачем нужен абстрактный интерфейс к monostate? Если monostate класс естественным образом реализует некоторую функциональность, которая может быть осмыслена как модуль, то абстрактный интерфейс к этому классу решает следующие задачи: а) осуществляет доступ к функциональности модуля б) реализует механизм сокрытия внешнего доступа к внутреннему устройству модуля в) определяет спецификацию методов доступа к данному классу. Эти задачи решаются просто разделением декларации и определения функций. И, кстати, к «абстрактности» интерфейса отношения не имеют. И декларации функций — это и есть описание интерфейса. В том смысле для которого вы определение привели. Декларация открытой функции при определении в хедере класса действительно является элементом интерфейса этого класса. Я же ввожу интерфейс для модуля - это более крупномасштабная единица в архитектуре програмной системы, которая может объединять несколько связанных по своей функциональной роли классов. QUOTE QUOTE (concolor @ Oct 20 2007, 13:15) г) позволяет легко менять различные реализации для данного интерфейса.Я не знаю что значит «легко». А вы? Легко по сравнению с чем? Вы пишите очень много буков, при этом так и не определились (по крайней мере здесь на форуме) с вашим вариантом использования того, что городите. Задайте себе вопрос: как и зачем это будет использоваться. Именно из наиболее точного и конкретного представления этого должно строиться решение. Пока у меня сложилось впечатление, что вы стремитесь сделать наоборот: поместить сферического коня в вакуум, а потом посмотреть зачем он нужен. В моем понимании если для смены реализации данного интерфейса нужно изменить одну строчку в исходнике, то это и значит, что сделать это легко. Мне кажется что легче уже некуда. Конкретно: template<class T = impl_Class1> меняем на: template<class T = impl_Class2> (да, при этом, конечно, typedef для impl_Class2 дожен быть заготовлен заранее) Ну и насчет сферического коня в вакууме - конструкция для определения абстрактного интерфейса к статическим классам мне потребовалась для четкой архитектурной организации моей системы формальной математики mdl (после достижения некоего критического уровня сложности). А именно, в парсере/прувере/трансляторе формальной математике есть несколько очевидных крупномасштабных структурных единиц типа monostate: -- парсер исходного языка - статический, ибо несколько экземпляров парсеров make no sense. Создается сразу при начале работы. -- внутри парсера подсистема - набор таблиц идентификаторов. Каждая таблица - в единственном экземпляре, создается сразу при начале работы. -- также внутри парсера - лексер, тоже monostate класс. -- модуль - хранилище уже доказанных теорем и аксиом. Очевидно, тоже monostate объект, который внутри себя имеет некоторую более мелкомасштабную структуру статических классов. -- подсистема вывода - ответственна за вывод результатов доказательств и трансляции в target. Тоже monostate со внутренней структурой. А теперь вопрос: в чем сферичность, где конь и почему в вакууме ?? http://forum.academ.org/html/emoticons/huh.gif

QUOTE (asv @ Oct 20 2007, 12:54) Когда то в универе на семинаре по ООП давали задачу "как создать экземпляр абстрактного класса?". Смысла не имеет никакого, но решение есть. Вот и тут то же самое... не согласен. Эта задача у меня возникла как раз на сугубо практическом уровне, поэтому смысл в этом есть.

QUOTE Чем не удобен monostate - нет чётко обозначенных фаз инициализации и разрушения. Т.е. не ясно, чем monostate отличается от простого набора функций в пространстве имён. Ну это относительно. В некоторых случаях нет смысла откладывать инициализацию (она происходит при старте програмы) и нет смысла выделять отдельно фазу разрушения. Если же эти фазы требуются, в интерфейс можно ввести методы init() и destroy(), осуществляющие их. Насчет отличия от набора функций в пространстве имен - да, действительно это очень похожие на monostate класс. Но, к сожалению, от пространства имен нельзя наследовать и нельзя объявлять функции в пространстве имен закрытыми - это можно делать только с классами. Поэтому именно для реализации интерфейса как спецификации и реализации методов доступа, обеспечивающих сокрытие реализации, пространства имен не годятся. QUOTE Ну а другая замена реализации в таком случае решается заменой файлов реализации. Причём это работает для любых языков. http://forum.academ.org/html/emoticons/wink.gif Мне кажется, что поменять дефолтный параметр у шаблона для замены реализации проще, чем заменить файлы реализации. http://forum.academ.org/html/emoticons/wink.gif Речь идет о языке с++, разумеется.

ок, попробую пояснить постановку задачи. Вначале о том, что такое "интерфейс" вообще (определение). Вот какое общее определение интерфейса дает wikipedia: QUOTE An interface defines the communication boundary between two entities, such as a piece of software, a hardware device, or a user. It generally refers to an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation, and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstractions of itself. Что же касается определения интерфейса в более частном случае - а именно интерфейса между частями (модулями) програмной системы, то wikipedia определяет интерфейс следующим образом: QUOTE The interface of a software module A is deliberately kept separate from the implementation of that module. The latter contains the actual code of the procedures and methods described in the interface, as well as other "private" variables, procedures, etc.. Any other software module B (which can be referred to as a client to A) that interacts with A is forced to do so only through the interface. One practical advantage of this arrangement is that replacing the implementation of A by another one that meets the same specifications of the interface should not cause B to fail — as long as its use of A complies with the specifications of the interface Ключевые места выделены жирным шрифтом. 1) почему простой typedef нельзя считать интерфейсом? Потому что а) отсутствует механизм сокрытия "внутренностей" реализации. Под внутренностями я имею в виду не только закрытые атрибуты и методы классов, но вообще все элементы реализации (включая хедер реализации, который дублируется интерфейсом). б) typedef не задает спецификацию методов доступа к модулю. 2) зачем нужен абстрактный интерфейс к monostate? Если monostate класс естественным образом реализует некоторую функциональность, которая может быть осмыслена как модуль, то абстрактный интерфейс к этому классу решает следующие задачи: а) осуществляет доступ к функциональности модуля б) реализует механизм сокрытия внешнего доступа к внутреннему устройству модуля в) определяет спецификацию методов доступа к данному классу. г) позволяет легко менять различные реализации для данного интерфейса. Для иллюстрации продолжу рассматривать таблицу идентификаторов как пример подобного модуля. Предположим, что есть несколько реализаций этого модуля и абстрактный интерфейс, определяющий спецификацию и реализацию методов доступа. Что если посторонний человек захочет модифицировать/добавить некую функциональность в этот модуль? Например кэширование, ведение логов или какой-либо статистики? Ему будет достаточно посмотреть на интерфейс и реализовать соответствующие методы (скорее всего путем модификации уже существующих модулей). Главное, что уже не будет возникать никаких вопросов - какие методы собственно и осуществляют интерфейс, так как они явным образом специфицированы в нем. P.S. компилируемый пример расположен в аттаче к первому посту.

предлагаю на суд уважаемой публики несколько своих мыслей, посетивших меня не так давно. Основным мотивом, сподвигшим меня на эти мысли стал (один из) девиз(ов) замечательного языка c++ "don't pay for what you don't use". I. Постановка задачи. Иногда в разрабатываемых програмных системах очевидным образом возникают объекты, которые существуют все время работы программы в единственном экземпляре. В качестве примера таких объектов можно привести таблицу идентификаторов при реализации парсера какого-либо формального языка. Практически все доступные в сети и в книгах источники наперебой рекомендуют в качестве решения этой задачи паттерн singleton. При первом же рассмотрении этот паттерн представляется очень сомнительным решением задачи в силу следующих причин: а) синтаксически таскать везде указатель на реализацию (instance) - очень громоздко, да и неэффективно (лишний inderection). б) выигрыш, связанный с возможностью отложенной инициализации синглетона не дает ничего, ибо заранее известно (в данной задаче), что этот объект будет 100% создан практически сразу после начала работы. Очень немногие источники упоминают паттерн monostate - это когда создается "чисто статический класс" - то есть класс, в котором все методы и атрибуты статические. Это уже гораздо лучше, поскольку обращение к методу такого класса очень компактно, удобно и не создает ненужных оверхедов. А теперь задача: как описать абстрактный интерфейс к классу-monostate ?? Виртуальные функции не могут быть static, поэтому, стандартный подход к определению интерфейса как чисто виртуального класса очевидно не проходит. Более того, любая попытка описать интерфейс к monostate классу при помощи виртуальных функций фактически приводит к indirection и необходимости где то хранить указатель на этот чортов виртуальный класс, то есть фактически возвращает к паттерну singleton. Так как же решить задачу не переплачивая за это корявым синтаксисом и косвенными обращениями? Я долго мучался, пока не понял правильное II. Решение задачи. Определим два namespace - abst и impl для включения в них интерфейсов классов и их реализаций соотвественно. Хедер для абстрактного интерфейса: namespace impl { class Stat; } namespace abst { typedef impl :: Stat impl_Stat; template<class T = impl_Stat> class Stat { public : static void run() { T :: run(); } }; } Хедер реализации интерфейса (#inlcude предыдущий хедер): namespace impl { class Stat { friend class abst :: Stat<>; private : static void run(); private : static int value_; }; } Сырец реализации интерфейса (#include предыдущий хедер) using namespace impl; int Stat :: value_ = 150; void Stat :: run() { cout << "stat works: " << value_ << endl; } Все! Если теперь для теста написать: #inlcude "хедер для реализации" int main() { abst :: Stat<> run(); } то, как и следует ожидать, будет вызван метод run() реализации класса impl :: Stat и на консоль выведется строка "stat works: 150". Что характерно, если попытаться вызвать impl :: Stat :: run(); то есть напрямую обратиться к классу реализации, то будет ошибка компиляции, ибо все методы класса impl :: Stat объявлены закрытыми. А abst :: Stat имеет доступ к реализации как friend. Вывод: класс abst :: Stat<> действительно скрывает (и кстати говоря абсолютно полностью!) внутреннее устройство реализации impl :: Stat с одной стороны, осуществляет полный доступ к реализации через себя, синтаксически практически так же удобен как и monostate (конечно, есть некая цена за конструкцию - скобки <> для вызова параметра шаблона по умолчанию) и не вызывает оверхедов эффективности из-за косвенных вызовов. Более того, ценой указания в скобках типа для реализации, можно осуществлять статический полиморфизм: если есть реализаци impl :: Stat2, то вызов abst :: Stat<Stat2> будет осуществлять доступ к этой реализации. Развивая эту конструкцию дальше, можно получить III. Интерфейсы для статического полиморфизма Действительно, повторив примерно ту же самую конструкцию, но уже не для чисто статических классов, а для произвольных, получим Хедер для абстрактного интерфейса: namespace impl { class Stat; } namespace abst { typedef impl :: Class impl_Class; template<class T = impl_Class> class Class : private T { public : void run() { T :: run(); } }; } Хедер реализации интерфейса (#inlcude предыдущий хедер): namespace impl { class Class { friend class abst :: Class<>; private : Class() : value_(250) { } void run(); private : int value_; }; } Сырец реализации интерфейса (#include предыдущий хедер) using namespace impl; void Class :: run() { cout << "class works: " << value_ << endl; } Если теперь для теста написать: #inlcude "хедер для реализации" int main() { abst :: Class<> class; class.run(); } то, как и следует ожидать, будет вызван метод run() реализации класса impl :: Сlass и на консоль выведется строка "class works: 250". Опять же, а) доступ к реализации класса impl :: Class будет возможен исключительно через класс abst :: Class, то есть abst :: Class - это действительно интерфейс к реализации impl :: Class б) нет оверхедов, связанных с вызовом виртуальных функций, как в случае виртуального интерфейса. в) возможен статический полиморфизм, когда выбор реализации интерфейса определяется параметром шаблона абстрактного интерфейса, например abst :: Class<Class2> для альтернативной (не дефолтной) реализации. IV. Выводы следующие - кроме стандартного понимания интерфейса как чисто виртуального класса существуют и другие, позволяющие за счет отказа от динамического полиморфизма избавиться от затрат на виртуальность и взамен получить статический полиморфизм. Ясно, что с (очень) большой вероятностью все вышеперечисенное является велосипедом, и уже давно широко известно в узких кругах. НО! хотя я усердно гуглил вопрос, никаких ссылок на это не нашел. А теперь вопрос: почему эти конструкции не являются широко известными и не включены в различные факи и тьюториалы? Если же эти конструкции имеют какие то серьезные изяны, то в чем они заключаются? Честно говоря, я не вижу в никаких недостатков, одни преимущества (например за счет гораздо более сильного сокрытия реализации - ведь в реализации все private). Но, поскольку общественность не ошибается, то я не прав. Короче говоря, чо не так то ?? http://forum.academ.org/html/emoticons/huh.gif P.S. добавил исходники примеров в приложение. StatInterfaceTest.tar.gz

QUOTE (D-Light @ Oct 19 2007, 18:55) Можно сегодня на сборе очно проголосовать. http://forum.academ.org/html/emoticons/rolleyes.gif это будет не корректно, поскольку при голосовании в пятницу вечером вероятность выбора варианта "пятница вечером" очевидно повышается, т.к. при этом голосовании не примут участие те, кто не может посещать "слеты" в пятницу вечером. http://forum.academ.org/html/emoticons/huh.gif

А мне все равно - пятница или суббота. Кстати неплохо было бы ввести соотвествующий пункт в голосовании.

QUOTE (gja822 @ Oct 18 2007, 17:28) Революции - в топку! Даёшь стабильность! http://forum.academ.org/html/emoticons/blink.gif а в 1996 году ты тоже голосовал "за стабильность" ?? http://forum.academ.org/html/emoticons/grin.gif

QUOTE (Aton-Ra @ Oct 18 2007, 14:08) QUOTE (concolor @ Oct 18 2007, 01:14) ты не отвечаешь на хамство, ты его начинаешь. Голословное утверждение, как ты говоришь. Покажи цитату, если сможешь. QUOTE Про хамство я тоже уже сказал - начинал не я. Про мой отказ обсуждать это в форуме тоже - если тебе делать нечего, можешь и дальше флудить на форуме. Я и так жалею, что потратил столько времени, составляя ответы на твои посты. Цитату - в студию. Пока что вижу неспровоцированное хамство - свидетельство слабости твоей позиции и отказ обсуждать. цитаты: 1) в сообщении Sep 16 2007, 18:38 QUOTE QUOTE То есть никаких репетиций эти "попевки" не заменяют. Учись читать, а? Где я говорил о замене? Фраза "Учись читать, а?" - это грубое обращение, показывающее презрительное отношение писавшего эту фразу к тому, кому она направлена. 2) там же QUOTE QUOTE Вывод: в качестве дополнения к текущей вялоклинической стагнации хора подобные "попевки" могут быть, но в качестве основы для качественного изменения нашего хора в лучшую сторону - никак не могут. Учись читать-2. Кто говорил про основу для качественного изменения нашего хора то же самое. 3) в сообщении Sep 16 2007, 19:21 QUOTE QUOTE Если ты не видишь, это не значит, что этого нет. Обязательны для исполнения например еженедельные сборы. Кроме того, регламент этих сборов может предполагать и конкретные мероприятия, обязательные для исполнения, но это уже детали. Какие сборы? Читай, на что отвечаешь. Речь про совет. Совет решил то-то и то-то. Это кого-то к чему-то обязывает? Обращение "Читай, на что отвечаешь." - грубое в данном контексте. 4) в сообщении Sep 16 2007, 19:57 QUOTE Хватит корчить всеми непонятого. Тебя все понимают, просто доводы у тебя слабоваты rolleyes.gif Реплика "Хватит корчить всеми непонятого" - откровенно грубая, это и называется хамством. 5) в сообщении Oct 11 2007, 23:28 очень много откровенных грубостей. QUOTE 2.1. Краткая история и сущность митизма. Под этим термином следует понимать прожектёрство, помноженное на непокобелимую веру в непогрешимость собственных идей. QUOTE Как и раньше, Митю не интересует критика и практическая реализация его гениального замысла. QUOTE 1. Попытка предложить новую концепцию без изучения истории вопроса особенно забавна в устах научного сотрудника. Ремарка про то, что это писано "с доброй улыбкой" - лицемерна. никакой "доброй улыбки" нигде в вышеперечисленных цитатах не просматривается.

QUOTE (VARVAR @ Oct 18 2007, 11:52) Заклинания и молитвы работают только у тех, кто живет лицензионную версию жизни. жесткач!! http://forum.academ.org/html/emoticons/jok.gif

принимай мои поздравления!! http://forum.academ.org/html/emoticons/biggrin.gif

QUOTE QUOTE (concolor @ Oct 17 2007, 20:06) понимаю, что это бесполезно, спорить с человеком, у которого очень слабо развито логическое мышление У меня в порядке не только логическое мышление, но и культура спора, поэтому на хамство я стараюсь не отвечать. О твоем уровне логического мышления сможет составить свое мнение любой человек, знакомый с формальной логикой по твоим предыдущим постам. Если уж ты заговорил о хамстве, перечитай pls свои предыдущие посты: ты не отвечаешь на хамство, ты его начинаешь. QUOTE QUOTE QUOTE QUOTE QUOTE Как и раньше, Митю не интересует критика и практическая реализация его гениального замысла. Голословное обвинение, не соотвествующее действительностиВ чём голословность? Ты же сам выше отказался обсуждать предложенные тобой идеи. Если я отказался обсуждать мои идеи с тобой (выше в по ветке), следует ли, что я отказываюсь обсуждать их со всеми? Твое утверждение НЕ ЛОГИЧНО. Если не понимаешь - читай учебники по логике (например Ю.Л. Ершов, Е.А. Палютин - "математическая логика"). На момент Совета был лишь один заведомо несогласный и одна критика твоей идеи - моя. Соответственно, моё обобщение - совершенно законно. А твой отказ обсуждать - слабость позиции и проигрыш в споре. Твое обобщение - не логично. Мой отказ обсуждать: мне жалко свое время и нервы тратить на бесплодные вещи. С вменяемыми людьми я вполне способен обсуждать свои и идеи и воспринимать критику. Слабость моей позиции пусть оценивают другие люди. Тебя я уже не собираюсь ни в чем убеждать. QUOTE QUOTE Кстати насчет моей цели. Моя главная цель - это такая организация хорового коллектива, где для всех желающих есть возможность расти профессионально (в певческом плане), и эта возможность не ограничена сверху. А устав - это средство достижения такой цели. Прочитай внимательно выше то, что я писал про историю вопроса и опыт профессионалов. Мнение и опыт профессионалов послушаем завтра на совете. Ах да, я совсем забыл, я же "по-тихому уговорил" всех профессионалов. Ну да, положение "якобы" беспроигрышное: если они будут поддерживать мои идеи - значит "по-тихому уговорил", а если нет - то "я же говорил!!!". QUOTE QUOTE Повторяю ещё два раза и медленно: я отказался то спора с тобой, поскольку спорить с неадекватным человеком БЕССМЫСЛЕННО. Мнения вменяемых людей меня ОЧЕНЬ ДАЖЕ ИНТЕРЕСУЮТ. Про хамство я уже сказал, а твои отговорки про мою неадекватность и невменяемость выглядят жалко. Повторю и я тебе: твой отказ обсуждать - слабость позиции и проигрыш в споре. Про хамство я тоже уже сказал - начинал не я. Про мой отказ обсуждать это в форуме тоже - если тебе делать нечего, можешь и дальше флудить на форуме. Я и так жалею, что потратил столько времени, составляя ответы на твои посты.

понимаю, что это бесполезно, спорить с человеком, у которого очень слабо развито логическое мышление, но все же на некоторые пункты отвечу (в последний раз). Чтобы было понятнее, я восстановлю оригинальные цитаты, на которые отвечал. QUOTE QUOTE QUOTE Как и раньше, Митю не интересует критика и практическая реализация его гениального замысла. Голословное обвинение, не соотвествующее действительностиВ чём голословность? Ты же сам выше отказался обсуждать предложенные тобой идеи. Если я отказался обсуждать мои идеи с тобой (выше в по ветке), следует ли, что я отказываюсь обсуждать их со всеми? Твое утверждение НЕ ЛОГИЧНО. Если не понимаешь - читай учебники по логике (например Ю.Л. Ершов, Е.А. Палютин - "математическая логика"). QUOTE QUOTE QUOTE В самом деле, зачем критика, если можно по-тихому уговорить Пашу, который никогда ни с кем не спорил или восхитить общественность количеством придуманных пунктов устава. Нет логики. а) Факт - 4 октября, в четверг именно я инициировал собрание совета хора, на котором преложил устроить обсуждение моего устава. Теперь вопрос: если бы я хотел "по-тихому уговорить Пашу" - зачем бы я инициировал собрание совета хора ? Это у тебя нет логики. Объясни, как одно мешает другому? И то, и другое служит твоей цели - протащить устав. Словосочетание по-тихому уговорить в авторской логике Антона Лукашевича (с) вовсе не противоречит обсуждению на совете хора. Кстати насчет моей цели. Моя главная цель - это такая организация хорового коллектива, где для всех желающих есть возможность расти профессионально (в певческом плане), и эта возможность не ограничена сверху. А устав - это средство достижения такой цели. QUOTE QUOTE б) Факт - 8 октября, в понедельник, я принес свой проект устава на хор в 5-ти экземплярах, чтобы все желающие могли ознакомиться и составить свое мнение. Теперь вопрос: если меня не интересует критика, зачем я распечатал 5 экземпляров проекта устава и давал читать всем желающим ? Неужели написавший это сам верит, что для того, чтобы "восхитить количеством пунктов"? Логики нет. Логика есть. Именно для этого. Чтобы принять этот устав. Критику ты получил ещё раньше, но отказался от спора. Повторяю ещё два раза и медленно: я отказался то спора с тобой, поскольку спорить с неадекватным человеком БЕССМЫСЛЕННО. Мнения вменяемых людей меня ОЧЕНЬ ДАЖЕ ИНТЕРЕСУЮТ. Вобщем надоело мне биться с ветряными мельницами - лучше не тратить зря время.

QUOTE (Aton-Ra @ Oct 17 2007, 18:55) Пока не увидел предложений по регламенту на завтрашнее заседание. Учитывая первое заседание, предлагаю следующее: A. Реорганизация хора. 1. Aton-Ra. 2. concolor. 3. Мыша или кто-то, кто хочет высказаться. По 5 минут на доклад, по 5 минут на вопросы. В сумме - не более 40 мин. B. Прения. 20 мин. C. Остальные вопросы. 0-5 мин. Замечания: 1) Паша Паластров тоже хочет высказаться на совете хора. 2) нигде выше в ветке не нашел реплики ув. Мышы о том, что она собирается выступить с отдельным словом. Может она высказала это желание в ЛС - тогда надо это подтвердить. 3) не понятно что имеется в виду под "остальными вопросами". Надо либо конкретизировать либо убрать этот пункт. Сооветственно мое предложение: A. Реорганизация хора. 1. Aton-Ra. 2. concolor. 3. Kadans64. По 5 минут на доклад, по 5 минут на вопросы. В сумме - не более 40 мин. B. Прения. 20 мин.

мне кажется забавной следующая картинка: http://forum.academ.org/html/emoticons/jok.gif вот бы ее отфотожабить... К сожалению я не умею =( может найдутся умельцы ?? взято тут ballmer.png

QUOTE (imiss @ Oct 13 2007, 16:39) QUOTE (Layоut @ Oct 13 2007, 13:55) фрифак Доколе???????? P.S. Да дайте уже кто нибудь Layout! +1. http://forum.academ.org/html/emoticons/huh.gif

QUOTE (Airin @ Oct 13 2007, 19:41) 21. B 24 "liberator" ?? http://forum.academ.org/html/emoticons/huh.gif

QUOTE (Airin @ Oct 13 2007, 19:34) 14. як 3 ... ?? http://forum.academ.org/html/emoticons/huh.gif

QUOTE Краткая история и сущность митизма. Под этим термином следует понимать прожектёрство, помноженное на непокобелимую веру в непогрешимость собственных идей. негативный эмоциональный фон (с) Даша. QUOTE Явление проявляет себя, как правило, следующим образом: Митя составляет план или сценарий культпрограммы, достаточно объёмистым куском текста или состоящий из многих пунктов. На вопросы по своему тексту он обычно отвечает примерно так: это, мол, пьянка, не надо напрягаться, репетировать и думать о деталях. Всё получится само собой. Организация "культпрограммы" качественно оличается от организации работы хора. И если в случае культпрограммы я, как и прежде, буду делать ставку на импровизацию, то в случае организации работы хора я делаю ставку наоборот, на жесткую структуру и детальное планирование. QUOTE Теперь нам предлагается очередной сценарий, но не культурной программы, а преобразования хора. Кроме этой маленькой детали от предыдущих случаев этот не отличается ничем. Во-первых, предлагается не "сценарий", а проект устава - свод принципов, по которым устроен хор, во-вторых, ничего общего со сценарием кльтурной программы устав хора не имеет. QUOTE Как и раньше, Митю не интересует критика и практическая реализация его гениального замысла. Голословное обвинение, не соотвествующее действительности + негативный эмоциональный фон (с) Даша. QUOTE В самом деле, зачем критика, если можно по-тихому уговорить Пашу, который никогда ни с кем не спорил или восхитить общественность количеством придуманных пунктов устава. Нет логики. а) Факт - 4 октября, в четверг именно я инициировал собрание совета хора, на котором преложил устроить обсуждение моего устава. Теперь вопрос: если бы я хотел "по-тихому уговорить Пашу" - зачем бы я инициировал собрание совета хора ? б) Факт - 8 октября, в понедельник, я принес свой проект устава на хор в 5-ти экземплярах, чтобы все желающие могли ознакомиться и составить свое мнение. Теперь вопрос: если меня не интересует критика, зачем я распечатал 5 экземпляров проекта устава и давал читать всем желающим ? Неужели написавший это сам верит, что для того, чтобы "восхитить количеством пунктов"? Логики нет. в) Факт - 11 октября, в четверг днем, перед собранием совета хора я настойчиво пытался по аське получить реакцию автора цитируемого сообщения на свой проект и его точку зрения на проблемы хора, на что не получил ответа (точнее полчил в форме "на собрании совета узнаешь"). Видимо это от того, что меня не интересует критика моего проекта устава. QUOTE И к чему Мите задумываться о практике, ведь, что бы не случилось, отвечать за всё будет Даша. не понятна логика этого высказывания + негативный эмоциональный фон (с) Даша. Проект устава предполагает четкое разделение отвественности за те или иные аспекты деятельности хора. Даша, как руководитель хора действительно является ответственной за многое (например за выполнение музыкальных и художественных задач), но и такой институт как совет хора также обладает весомой отвественностью, в частности по организации репетиционного процесса. Кроме того, на совете хора Даша совершенно недвусмысленно дала понять, что она не хочет заниматься вопросами организации репетиционого процесса и ждет, когда ответственность за это возьмет на себя та или иная структура хора. QUOTE 2.2. Репетиции. Две репетиции по 2 часа – необходимый минимум для разучивания одной программы. Точнее – это столько, сколько нужно для сохранения уже разученного. Как в спорте: 1 тренировка - бесполезно, 2 - сохранение формы, 3 - стабильный прогресс. Хормейстеров (один либо двое) не хватает даже на этот минимум. Есть понятие ресурсов. Их столько, сколько есть. И внешних хормейстеров у нас столько, сколько есть, взять и найти ещё несколько наш хор не может. Из этого я делаю однозначный вывод - внутри хора нужно воспитывать (образовывать) продвинутых людей для выполнения (частичного) роли хормейстеров. QUOTE Из практики многих лет мы приходим к выводу, что наименьшее количество репетиций для самодеятельных хоров две в неделю. При одной репетиции в неделю результаты проделанной работы почти без остатка рассеиваются к следующей, приобретенные навыки сглаживаются. При этих условиях результаты не ощущаются, у певцов падает интерес к работе. зачем это было писать - у нас в хоре так и есть минимум 2 репетиции в неделю, и мой проект устава хора не предполагает уменьшения количества и длитеьности репетиций. QUOTE Разбивать хор на группы – значит либо гарантировать хору 3-4 хормейстера (т.е. увеличить их число на 2 человека), либо бросить силы на ансамбль высшего класса и обрекать большую часть хора на регресс. неверные логические заключения. Моя логика прямо противоположна. Как раз в ситуации недостатка хормейстеров силы предлагается бросать на новичков, а продвинутые группы поставить в ситуацию, когда большая часть рутинной работы с репертуаром будет осуществяться ими автономно. Тем самым разбиение хора на группы необходимо для того, чтобы максимально использовать имеющиеся ресурсы (время и хормейстеров). QUOTE Люди, молчащие во время репетиций и концертов, будут задавать себе вопрос: «А зачем?» В результате останутся лишь те, кто ходит по инерции или пообщаться, а те, кто имел слабый уровень, но хотел достичь многого, поймёт, что ему здесь не место. Из моего проекта устава хора не следует, что будут люди, молчащие во время репетиций. Если часть хора, молчит на концертах при исполнении произведений, которые им не по силам - с моей точки зрения, это совершенно нормальная ситуация, более того, практикуется и в нашем хоре. Те, имеют слабый уровень но хотят достичь многого имеют очевидную перспективу - поднять свой уровень и перейти в следующий класс, что всецело должно поощряться. Почему из этого следует, что они должны понять, что им не место в хоре - вменяемый человек понять не в состоянии. QUOTE 2.3. Выступление. Исходя из фактической посещаемости репетиций, при любом раскладе хор будет поделен на 3 ансамбля по 5-10 человек. Выступать отдельно как «ХОР НГУ» 1-й класс не сможет - это будет не хор, и даже не камерный хор. Автору вышепроцитированного рекомендую повнимательнее ознакомиться с проектом устава. Поскольку 1-ый класс (начальный) выступать отдельно от остального хора не может в принципе, ибо имполняемый им репертуар - базовый - должны знать абсолютно все, поющие в концерте. Если же имелся в виду 3-й класс, то его численность не постоянна во времени. На начальном этапе, после принятия устава, предполагается что ВСЕ участники хора входят в 1-ы класс. Через некоторое время, после проведения "сессии", появляется несколько человек 2-го класса. Потом, после ещё одной сессии, численность 2-го класса может увеличиться и появиться хористы 3-го класса и т.д. По прошествии достаточно большого промежутка вермени (год-полтора), есть вероятность как раз деления на 3 сравнимые по размеру группы, причем вторая - самая многочисленная. Соотвественно: 3-й класс выступает ансамблем (5 чел) и исполняет продвинутый репертуар, 2-й класс вместе в 3-им выступает как основной состав хора (12 - 15 чел) - и исполняет общий репертуар, ну и все три класса образуют общий состав хора (исполняют базовый репертуар). QUOTE Хор отличается от вокального ансамбля (вокального трио, квартета, квинтета и т. д.) наличием как минимум двух (по П. Чеснокову, трёх) или более человек исполняющих одну и ту же партию. спасибо за определение хора по Чеснокову. Будем знать. QUOTE Следовательно, предполагается выступление с двумя программами, когда одна программа поётся всеми, другая – лишь избранными. Неверно. Во времении распределение хора по классам меняется от сессии к сессии. Поэтому вначале все в 1-ом классе и программа одна - базовая. Потом возникает 2-ой класс, и первоочередная задача 2-ого класса - создание ансамбля, что позволяет разгрузить хормейстеров для работы с 1-ым классом. Потом возникает 3-й класс и концертный ансамбль, что действительно разделяет программу выступлений на базовую и выступление концертного ансамбля. А вот потом, когда численность хористов класса не менее 2-го превышает некую критическую, выступление хора может разделиться на 3 части: базовую, общую и продвинутую. при этом "избранными" могут быть 2/3 всего состава хора. QUOTE У зрителя будет возникать недоумение: почему одна часть хора поёт, а другая - нет? В случае джазового ансамбля вопросов не возникало: в силу специфики жанра и дистанцирования ансамбля от хора это выглядело более-менее естественно. Я тоже иногда бываю зрителем, и если бы увидел такое - у меня бы не возникло никакого недоумения. Раз поют не все, значит ТАК НАДО. QUOTE Здесь же контраст будет бросаться в глаза зрителям и, в перспективе, негативно влиять на психологическую атмосферу в хоре. насчет контраста, бросающегося в глаза зрителю - это субъективное мнение автора цитируемого сообщения. Насчет психологической атмосферы - то же самое. Не вижу тут проблем. Если человек пока не обладает нужной квалификацией для пения некоего произведения, знает это, и при его исполнении не поет - то почвы для психологического дискомфорта я не вижу. QUOTE Итак, концерт будет выглядеть проходить по одной из трёх схем: a) Выступает высший класс как ансамбль Хора НГУ. Возникнет вопрос: а где Хор и почему он не пришёл? б) Выступает Хор с двумя программами и удивляет зрителей молчащими во время исполнения хористами и тем, что на некоторых произведениях хор звучит как пол-хора. c) Поётся одна программа и разделение теряет смысл. вариант а) практиковался и ранее и неоднократно (выступал ансамбль хора) - почему то вопросов типа: "а где Хор и почему он не пришёл?" не возникало. Почему такие вопросы должны возникать в случае принятия устава хора - непонятно. вариант б) тоже практиковался в малых масштабах, когда отдельным хористам рекомендовалось не петь во время исполнения тех или иных произведений. Ещё раз подчеркиваю, что разделение программы на концертах происходит не сразу при принятии устава, а только при накоплении критической массы хористов нужной квалификации. При этом продвинутые 1/2 хора (а на самом деле скорее даже 2/3), просто в силу своей квалификации, будут звучать не как пол-хора, а как 3/4 хора, если не больше. вариант с) наследуется естественным образом хором в случае утверждения устава на некоторое время (возможно даже довольно продолжительное). QUOTE Простые вещи скучно петь, особенно любителям. правильно. И это является мощным стимулом для поднятия своей квалификации хористами. Естественно, в случае когда репертуар увязывается с этой квалификацией (классом). QUOTE Мы не поём сейчас ничего особо сложного, поэтому неубедитльно выглядят аргументы о том, что кто-то не учатся, потому что материал непосилен. Хотелось бы услышать второй номер (глорию) из мессы Гайдна целиком в сольном исполнении автора цитируемого сообщения. Если он считает это не сложным - пусть продемонстрирует это. QUOTE Если человек принципиально не попадает в ноты или у него нет никакого опыта - тогда, действительно, таким стоит дать возможность заниматься в отдельной группе, но обучать именно попадать, слушать и строить, чтобы они могли скорее присоединиться к концертной группе. С моей точки зрения утверждение верное, но это прямо противоречит вышеприведенным высказываниям автора цитируемого сообщения ("Разбивать хор на группы – значит либо гарантировать хору 3-4 хормейстера (т.е. увеличить их число на 2 человека), либо бросить силы на ансамбль высшего класса и обрекать большую часть хора на регресс"). То есть автор цитируемого сообщения с одной стороны критикует мою идею разбиения хора на группы, с другой стороны - предлагает выделить особую группу в хоре. Где логика? QUOTE Разделение хора кому-то может показаться палочкой-выручалочкой, которой можно в короткие сроки решить все проблемы. Нигде ни в уставе, ни в моем ответе на цитируемое сообщение я не говорю о коротких сроках. Наоборот, по моим оценкам, переход на функционирующую структурированную организацию для хора займет не менее года (а возможно и более). QUOTE Но вместо эволюционного пути предлагается революционный, вместо терапии – хирургия. эмоциональный фон (с) Даша. QUOTE Странная позиция: человеческие методы, признанные всеми, в нашем хоре действовать не могут в принципе (и не важно, что мы их даже не пробовали), поэтому испробуем нечеловеческие. Классическая система образования (более чем тысячелетняя), основанная на ступенях квалификации и переходе между ними на основе зачетов и экзаменов - по логике автора цитируемого сообщения это нечеловеческий метод. QUOTE Выводы. Выводы. QUOTE 1. Попытка предложить новую концепцию без изучения истории вопроса особенно забавна в устах научного сотрудника. историю вопроса в нашем хоре я знаю лучше, чем автор цитируемого сообщения (в хоре НГУ я состою 12 лет, с 1995 года) + негативный эмоциональный фон (с) Даша. QUOTE 2. Предложенный устав не предусматривает механизмов контроля за его выполнением, поэтому является лишь кучей абстрактно-благодушных пожеланий. контролем за исполнением устава занимаются "ветви власти" хора: руководитель и совет. Основой для соблюдения устава является его принятие и согласие придерживаться его положений составом хора и руководством хора. При возникновении ситуации несоблюдения, на совете хора может ставится вопрос о дальнейшей судьбе устава: либо его изменении для соотвествия текущему положению дел, либо о исправлении нарушений. Это единственное ценное замечание в цитируемом сообщении (несмотря на негативный эмоциональный фон (с) Даша). Необходимо включить соответствующие пункты в устав. QUOTE 3. Схема разделения репертуара и хора на классы противоречит практике хорового дирижирования. Выделение из хора класса типа "ансамбль" (по факту - продвинутые хористы) - противоречит практике хорового дирижирования ? QUOTE 4. От предложенной организации при фиксированном лимите хормейстеро-часов проиграет каждый хорист любого класса. Неверное утверждение. От предложенной организации каждый хорист на начальном этапе ничего не получит и не потеряет, а в перспективе выиграет, за счет высвобождения ресурсов для работы с новичками и повышения автономности (а следовательно и ответственности) для продвинутых хористов. QUOTE 5. Профессиональные вопросы не могут решаться непрофессионалами. Даже став профессиональным певцом, хорист при этом не становится профессиональным хормейстером. Голосование сотни неспециалистов имеет нулевую ценность по сравнению с мнением специалиста. Это и есть перекладывание всей отвественности за хор на Дашу и хормейстеров. Видимо вышесказанная фраза "ведь, что бы не случилось, отвечать за всё будет Даша" является не случайной. При том, что Даша открытым текстом сама сказала, что ей не интересно этим заниматься. Профессионализм в дирижерской деятельности конечно же связан с организационной деятельностью, но далеко не настолько однозначно, что решением организационных проблем хора может заниматься исключительно человек со спец образованием. QUOTE 6. Организация и методы работы хора находятся в компетенции хормейстера. Методы работы - да, находятся в компетенции хормейстера. А вот организация работы - это общая забота. QUOTE 7. Возлагая на себя функции хормейстера, хор декларирует профессиональную беспомощность своего руководителя. Подмена понятий (причем странная какая то). Мой проект устава не предполагает, что хор возлагает на себя функции хормейстера. Этот проект разделяет различные аспекты деятельности хора, вводит в хор структуру и функциональные роли участников хора, прописывает общие механизмы репетиционной и не только работы. Да, устав хора становится обязательным для исполнения документом (фактически конституцией хора), но во-первых, он должен в обязательном порядке быть одобрен руководителем хора, и во-вторых он может корректироваться в будущем. При чем тут профессиональная беспомощность руководителя - вообще не понятно.

хочу поделиться впечатлениями от вчерашнего доклада. СУПЕР!! http://forum.academ.org/html/emoticons/cool.gif У вчерашнего докладчика природный талант рассказывать всякие интересные вещи в научно-популярной манере. Честно говоря, я наверное не смог бы так живо и остроумно рассказывать. Но если придется встать "к барьеру" - по крайней мере у меня теперь есть образец, к чему нужно стремиться. Что касается минусов - они к сожалению тоже есть... Докладчика по ходу доклада засыпали вопросами и репликами со всех сторон, часть из которых, по моему мнению, можно было бы и опустить - в результате доклад затянулся и я так и не смог дослушать до конца (мне надо было уходить)....