OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 12 Декабрь, 2019 11:40

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 179 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.
Автор Сообщение
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 13:23 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4539
Откуда: Россия, Орёл
Тема и так раздута. Оффтопы режутся.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 14:05 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Geniepro писал(а):
Александр, да у Вас прямо талант объяснять! Я наконец понял о чём чешут языками в этой теме... :lol:
Попробую внести свои 5 копеек. На более абстрактном уровне, которой мне ближе и понятнее. Тешу себя надеждой, что и Вас (а вдруг).

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

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

Выход конечно же есть: не получается почесать ухо рукой, можно и ногой. Типа "проблема решена". Решена еще в паттернах от банды 4-х. Называется паттерн Command.
Существует другое решение проблемы - она изложена как цитата из Мюллера. Коротко, понятно, ни одной новой сущности.
(BTW: в дисере Мюллера слово DELEGATE не встречается вообще. Предполагаю, народ подумал, и сказал: "да нафиг оно нужно...")
Мое мнение - позволяющее создавать более прозрачный и надежный код в парадигме ООП.
Конечно же, присвоить, чтобы тут же снова вызвать - не особо и нужно. Так же как и процедурный тип нафиг не нужен только чтобы тут же вызвать.И Ваши сомнения из серии "а нафига" - совершенно справедливы.
Нужны эти типы для придания каких-то полиморфных средств некому методу (объекту). А вовсе не для того, чтобы: "кинеся, а воно Е"
В процедурном программировании процедура сортировки, параметризированная процедурным типом сравнения становится более универсальной. Типа это и есть огромное удобство процедурного типа.
В ООП, та же функция сравнения захочет знать над каким объектом она сравнивает-то. Грубо говоря, сравнение - это метод какого-то объекта, и таковых объектов может больше одного (ну надо же).

Это не буйство фантазии, это реальная жизнь - уже захотели, смотрим в MSDN описание LVM_SORTITEMS Message.
Ну вот и все, по мнению Ильи - "по отдельности" все в порядке будет.
А по моему - некрасивые самолеты не летают. Ну или (по мнению прапорщика из анекдота) - летают, но низко-низко :lol:
Об этом и разговор.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 14:16 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Galkov писал(а):
Оказывается, наступает эра ООП. Отчего-то нормальным людям оказывается проще формулировать свои мысли в этой парадигме... Не будем обсуждать в этом топике, примем это как экспериментальный факт, как бы это не было противно окружающим.


Нет никакой "эры" и никакого "ООП".
Есть механизмы расширения, полиморфизма, позднего связывания. МЕХАНИЗМЫ.
Лучше, если они представлены по отдельности, а не едино и с "комфортом".

Цитата:
И чего получается - удобство процедурного типа пошло псу под хвост. Обыдно, да ???


И никто не думает об "удобствах" процедурного типа, и куда оно там пошло.
Есть механизм. Просто механизм. В его задачи обеспечивать какой-то там комфорт не входит.
В задачи механизма входит:
- работать простым и предсказуемым образом;
- быть применимым в как можно большем числе задач.
Удобно или не совсем удобно - неважно.

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

Цитата:
В процедурном программировании процедура сортировки, параметризированная процедурным типом сравнения становится более универсальной. Типа это и есть огромное удобство процедурного типа.


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

Цитата:
В ООП, та же функция сравнения захочет знать над каким объектом она сравнивает-то. Грубо говоря, сравнение - это метод какого-то объекта, и таковых объектов может больше одного (ну надо же).

Это не буйство фантазии, это реальная жизнь - уже захотели, смотрим в MSDN описание LVM_SORTITEMS Message.
Ну вот и все, по мнению Ильи - "по отдельности" все в порядке будет.


Вот в том-то и беда - что "уже захотели". А я не хочу, чтобы функция сравнения чего-то там знала. Не хочу читать код, где она будет такой "умной". И не хочу выслушивать критику, что в мире моих инструментов функции сравнения ничего "не знают". Потому что и не нужно им знать, этим сравнениям.

Цитата:
А по моему - некрасивые самолеты не летают. Ну или (по мнению прапорщика из анекдота) - летают, но низко-низко


Критерий красоты "вообще" - не имеет смысла. Бывает красота как следствие действительно удачности. Но это только следствие, а никак не причина.
C++ тоже красивым можно назвать, как абстрактно рассматриваемый изыск в области формальных текстов. Я НЕ считаю его НЕкрасивым, например.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 14:21 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 531
Откуда: Москва
Galkov писал(а):
Об этом и разговор.
Вы вывод-то сформулируйте. А то разговор есть, но непонятно куда он ведет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 14:47 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Дык я уже давно сформулировал...
Вон Илья пишет:
Цитата:
- работать простым и предсказуемым образом;
- быть применимым в как можно большем числе задач

Есть два кода, сравнивайте. Без громких слов про "механизмы", и т.п..
Мне кажется, что код Ильи будет работать менее простым и предсказуемым образом. И применим в меньшем числе задач.

Если кто-то видит черное – белым, настаивать не буду.
Указанную "ненадежность" заталкивать в рот - тоже. Хватит и того, что разжевано.
Не то, чтобы в лом - меня не устраивает предложенный стиль.

Для меня топик был полезным в двух аспектах.
Что мне стали понятны истинные мотивы использования высокоумных словов на форуме.
И что Оберон - это не только КП. Грубо говоря, стиль применения Окамма и Калашникова, излагаемый на форуме, не есть характерная черта именно Оберонов.

Что радует. Потому что изюминка-то в Оберонах есть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 15:01 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Как раз дурной пример - попытки обобщать алгоритмы (начиная от параметров процедурного типа и кончая библиотеками шаблонов) - плохая затея. С нашей, конечно, точки зрения. Контейнеры и обобщённые алгоритмы, есть у меня такое убеждение, малополезны.

Илья, не могли бы вы в свободное время объяснить почему? Потому как интуитивно такой вывод определённо не напрашивается. И почему каждый раз, когда нам нужен список, мы должны его вручную под конкретный тип данных писать? Причём, так как это утомительно, выйдет он не приличным, как в Делфи TList, а примитивным линейным с последовательным доступом.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 15:08 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Александр Ильин писал(а):
Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы).
Вот! Спасибо. Теперь понял окончательно, что херня.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 16:16 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Berserker писал(а):
Цитата:
Как раз дурной пример - попытки обобщать алгоритмы (начиная от параметров процедурного типа и кончая библиотеками шаблонов) - плохая затея. С нашей, конечно, точки зрения. Контейнеры и обобщённые алгоритмы, есть у меня такое убеждение, малополезны.

Илья, не могли бы вы в свободное время объяснить почему? Потому как интуитивно такой вывод определённо не напрашивается. И почему каждый раз, когда нам нужен список, мы должны его вручную под конкретный тип данных писать? Причём, так как это утомительно, выйдет он не приличным, как в Делфи TList, а примитивным линейным с последовательным доступом.

Я об этом тоже в последнее время много думал. Но пришел к противоположному выводу. Мой личный опыт показывает, что в 99% я использую TList как "примитивный и линейный", а в оставшемся 1%, "приличность" TList мне ничего не дает, приходится прикручивать, что-то свое. Ну и ...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 18:30 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Info21 писал(а):
Александр Ильин писал(а):
Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы).
Вот! Спасибо. Теперь понял окончательно, что херня.


Правильно ли я понимаю, что Oberon-2 с его ООП "как у всех" (т.е. интерфейс-класс-объект) - это тупиковая ветвь эволюции оберонов?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 19:24 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Удалено модератором.

Axcel писал(а):
Я об этом тоже в последнее время много думал. Но пришел к противоположному выводу. Мой личный опыт показывает, что в 99% я использую TList как "примитивный и линейный", а в оставшемся 1%, "приличность" TList мне ничего не дает, приходится прикручивать, что-то свое. Ну и ...

От списка нужно:
1) Прямой доступ к любому элементу по индексу (без прохождения по цепочке связанного однонаправленного списка).
2) Возможность добавления элемента (умный алгоритм выделения памяти, например рост 100% при нехватке места).
3) Возможность удаления, очистки, поиска по ключу.

Это то, что в целом требуется от контейнера. Фактически, список - это расширенный динамический массив. Реализовывать списки для каждой структуры данных напряжно и бессмысленно. Всё равно, что каждый раз вручную писать аналоги процедур из стандартной библиотеки.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 19:31 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Berserker писал(а):
От списка нужно:
1) Прямой доступ к любому элементу по индексу (без прохождения по цепочке связанного однонаправленного списка).

Это не список :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 19:56 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
А что же ещё? Порядковый номер элемента - индекс. Многие современные ЯП не разделяют списки от массивов. php, javascript - массивы = списки = стёки (с операциями добавления, удаления, поиска по ключу и при этом прямым доступом). Вопрос лишь в расширении и скорости доступа. В традиционном примитивном списке для доступа к элементу с индексом N нужно пройтись по всем, что до него. Если в основу положить динамический массив, то доступ мгновенный. И такой список универсален и удобен в большинстве случаев.

Википедия:
Линейный однонаправленный список - то, что вы понимаете под "списком", хотя список не ограничивается такой интерпритацией.
"В зависимости от реализации может быть возможен произвольный доступ к элементам списка." - подтверждение моих слов.

Линейный однонаправленный список не масштабируем. На тестах было 10 элементов, в реале - 1000. И каждое обращение - в среднем 500 операций доступа.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 20:03 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Прохоренко писал(а):
Правильно ли я понимаю, что Oberon-2 с его ООП "как у всех" (т.е. интерфейс-класс-объект) - это тупиковая ветвь эволюции оберонов?
Да, да.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 20:20 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Berserker писал(а):
Википедия:
Линейный однонаправленный список - то, что вы понимаете под "списком", хотя список не ограничивается такой интерпритацией.
"В зависимости от реализации может быть возможен произвольный доступ к элементам списка." - подтверждение моих слов.

Я бы ЭТО назвал бы линейным контейнером.

Berserker писал(а):
Линейный однонаправленный список не масштабируем. На тестах было 10 элементов, в реале - 1000. И каждое обращение - в среднем 500 операций доступа.

Если регулярно обращаться по индексу, то да :-)
А так он вполне масштабируем. Вы просто не умеете его готовить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 20:23 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Berserker писал(а):
Линейный однонаправленный список не масштабируем. ...

Да-а-а... вот так вот и вылазит страшная подоплёка.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 23 Декабрь, 2010 21:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Berserker писал(а):
Другой пример. Ассоциативные массивы (хэш-массивы). Модуль в 600 строк должен уметь работать с абстрактным типом данным, иначе какой-то садомазохизм выходит. Если отказываться от абстрактных контейнеров, то нужно приходить к шаблонам и всем проблемам, с ними связанными.


А что там делать-то с этими хэш-массивами? Часто делаю.

ARRAY N OF Item,
где Item - голова связного списка.

Далее хэш от ключа - и вперёд линейным поиском среди коллизий в нужном пункте таблице.

Ну да, есть категория применений - бизнес-приложения, приложения, сопрягающиеся с интернет-мордами и JavaScript, где мне уже хочется завести какой-то универсальный ассоциативный контейнер, типа как объект в JavaScript. Чтобы хранить иерарахию объектов, доступным по символьным именам. Но это ярко выраженная прикладуха ИС-овского характера.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 24 Декабрь, 2010 07:10 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2318
Откуда: Россия, Томск
Geniepro писал(а):
Александр, да у Вас прямо талант объяснять! Я наконец понял о чём чешут языками в этой теме... :lol:

Конкретно в данном примере возникает вопрос -- на что указывает do, если объект obj2 уничтожен? Или же его нельзя уничтожить, пока где-то висит ссылка на его метод Do?
В Обероне такая процедурная переменная должна служить "якорем" связанного объекта для сборщика мусора, т.е. объект не будет удалён из памяти, пока есть процедурные переменные, указывающие на его методы. В Delphi, где удаление объектов ручное, надо следить самостоятельно, а при вызове метода удалённого объекта через процедурную переменную будет то же самое, что при обычном вызове метода удалённого объекта (как правило, будет исключение из-за ошибки доступа к памяти, но не всегда).
Geniepro писал(а):
И ещё, вот конкретно в данном примере можно было бы вполне обойтись таким вариантом:
Код:
VAR obj: SomeObject;
obj := obj1;
obj.Do(); (* вызывается obj1.Do *)
obj := obj2;
obj.Do(); (* вызывается obj2.Do *)
Это сработает только в том случае, если obj1 и obj2 имеют тип SomeObject либо наследуются от SomeObject (иначе не скомпилируется присваивание), и метод Do объявлен в SomeObject, а не в унаследованном типе (иначе не скомпилируется вызов метода). В предлагаемом же варианте с {DELEGATE} объекты могут быть абсолютно независимы иерархически, достаточно только совпадения списка формальных параметров методов, что и проверит компилятор (в примере список пустой). Точно так же, как в обычную процедурную переменную можно присваивать процедуры из несвязанных друг с другом модулей при условии совпадения списка параметров, так и в переменную {DELEGATE} можно присваивать методы любых объектов при условии совпадения списка параметров.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 24 Декабрь, 2010 07:32 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2318
Откуда: Россия, Томск
В Delphi главное применение procedure of object - это обработка событий, т.е. объектные callback-и. Есть даже стандартный тип (наиболее часто используемый):
TNotifyEvent = procedure (Sender: TObject) of object;
Многие объекты VCL публикуют "разъёмы" для подстановки обработчиков событий. Например, если есть объект TButton, то у него наверняка будет событие OnClick: TNotifyEvent;
Допустим, мы поместили к себе на окно эту кнопку, и хотим при нажатии на неё что-то посчитать. Окно - это объект типа TMyForm:
Код:
procedure TMyForm.Create();
var btnOK: TButton;
begin
   btnOK := TButton.Create();
   // положили кнопку в нужное место, настроили внешний вид
   btnOK.OnClick := DoOKClick;
end;

procedure TMyForm.DoOKClick(Sender: TObject);
begin
   // обработка щелчка по кнопке OK
   // Sender = btnOK, можно привести к типу TButton
end;

// Кнопка делает вот что
procedure TButton.Handle...
begin
   // если назначен обработчик, вызовем его
   if OnClick <> nil then OnClick(Self);
end;
Ключевая строчка: btnOK.OnClick := DoOKClick;
По сути, это присваивание процедурной переменной. НО! Эта процедурная переменная должна вызываться для конкретного экземпляра TMyForm, ведь ничто не мешает нам создать три экземпляра объекта типа TMyForm и вести независимые подсчёты в каждом из них. Вот поэтому используется тип procedure of object со скрытой ссылкой на экземпляр объекта TMyForm. На этом механизме построена вся обработка событий в библиотеке Delphi VCL (кроме событий от ОС).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 24 Декабрь, 2010 08:16 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Александр Ильин писал(а):
В предлагаемом же варианте с {DELEGATE} объекты могут быть абсолютно независимы иерархически, достаточно только совпадения списка формальных параметров методов, что и проверит компилятор (в примере список пустой). Точно так же, как в обычную процедурную переменную можно присваивать процедуры из несвязанных друг с другом модулей при условии совпадения списка параметров, так и в переменную {DELEGATE} можно присваивать методы любых объектов при условии совпадения списка параметров.

Вот это, наверное, не совсем правильно, идеологически, по крайней мере. Для таких целей и нужны более современные системы типов, включающие классы типов или хотя бы интерфейсы в стиле Ява/C#.

Если объекты не имеют совершенно ничего общего, то, вероятно, и смысл их методов тоже отличается. Зачем же их перемешивать? Скорее всего это ошибка, ну или легко можно будет допустить ошибку в таких условиях. А если бы была поддержка интерфейсов/классов типов, то такие ошибки отследил бы компилятор.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 24 Декабрь, 2010 11:27 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Вы неправы, все тут правильно.
Посмотрите на игрушечный ((с) И.Ермаков) пример. Семантика MediaPlayer.Play и MediaPlayer.Stop - совершенно различна. Не имеющая ничего общего с System.Reboot. Но они прекрасно уживаются в переменной одного типа.
Нет тут никаких идеологических неправильностей. Все именно так и задумано.

А вот проблемы у CPP-шников - есть: "ай, вот мы сейчас нарисуем шаблоны, а компилятор всю эту прорву (зачем-то) типов соптимизирует в один". Не, не оптимизирует (полностью, по крайней мере, ибо самые продвинутые компиляторы о чем-то начинают таки догадываться)

Между прочим, у меня уже несколько таких бесед было...
С коллегами, которых на данном форуме принято называть "программист пальцы веером". Мое личное наблюдение: народ понимает таки аргУменты. Сетуют, конечно же, на компилятор: "вот гад, вся же информация у него есть!!!" Но логикой владеют на более высоком уровне, чем поиск нужной фразы в цитатнике :D


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 179 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Bing [Bot] и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB