OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 06:43

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




Начать новую тему Ответить на тему  [ Сообщений: 17 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 31 Май, 2016 09:57 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Отделено от: viewtopic.php?f=127&t=5680 по запросу автора исходной ветки.

ilovb писал(а):
Программировать можно вообще без VAR и ничего при этом не изменится в смысле вычислений.
То же самое можно сказать про функции. Но Вы наверняка не обвините функции в отсутствии концептуальности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 10:00 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Почему же не обвиню. Обвиню! :)
Всегда считал, что в оберонах функции - просто мелкий сахар.

Вот процедуры из языка уже не выкинешь. Все ломается и теряет смысл.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 11:45 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Соглашусь, что функция -- "мелкий сахар", но потому она и есть, что "мелкий". не вводится новое "корневое" понятие.
Также соглашусь с VAR -- "мелкий сахар", не имеющий какого-то особого смысла ( в отличии от IN и OUT).
Средствами компилятора легко, имхо, делается на выбор передача по фактическому значению, и передача по ссылке.
Оба сахарка незначительны. Можно мириться. Если сравнить с приснопамятным питоном (третьего разлива), где хелперы втыкаются в описание параметров в процедуре, а затем ВООБЩЕ не используются -- да VAR просто детский лепет)))
Да, не идеально. Но работает с достаточной простотой и надёжностью.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 19:48 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
ilovb писал(а):
Если хочется настоящих концепций про контроль доступа, то это в Rust. Или там в уровни изоляции транзакций в СУБД.


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

Таким образом, какая-то базовая защита от неправильного втыкания "вилки не той стороной" вполне оправдана.

Цитата:
Вообще, имхо, методы нужно воспринимать как сообщения. Мы посылаем объекту сообщения, а как на них реагировать, решает сам объект. В идеале к кишкам объекта доступа быть вообще не должно, а все свои инварианты объект сохранит сам.


Да в случае со статически размещённым RECORD я бы вообще не говорил о какой-то объектной семантике. Это тупо тип данных с множеством операций. Не более, не менее.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 19:52 
Модератор
Аватара пользователя

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


А почему только системами? Или почему процедура не система? Условности это...
Без схоластики, интерфейс возникает там, где есть что-то кроме интерфейса (скрытое, чьи изменения не видны за неизменным интерфейсом). Т.е. как только объективно есть скрытое внутреннее устройство, так возникает и интерфейс.
В этом конкретном смысле - вполне себе интерфейс... Который может быть подинтерфейсом большего интерфейса.

У тебя установка X имеет интерфейс из 10 кабелей. А каждый кабель - свой подинтерфейс )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 20:33 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Илья Ермаков писал(а):
У тебя установка X имеет интерфейс из 10 кабелей. А каждый кабель - свой подинтерфейс )

Совершенно в тютельку.
Для меня Вселенная вообще делится на процессы и объекты.
У объектов неизбежно появляется интерфейс, и процесса сокеты (вход, выход, безразличный). И если у объекта есть изолированные части, то он по отношению к своим изолированным объектам может сам являться процессом. Короче, матрёшка.

Таки образом RECORD, это действительно всего лишь кусок данных. Объекты. Процедуры, знают как данные переваривать и, если нет статических членов -- чистые процессы. (* разумеется на практике абсолютных выражений идей не существует, всегда какая-то смесь *)
Методы, имхо, тот самый ненавязчивый сахарок. Но привыкание вызывает)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 22:08 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Илья Ермаков писал(а):
Таким образом, какая-то базовая защита от неправильного втыкания "вилки не той стороной" вполне оправдана.


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

Илья Ермаков писал(а):
Цитата:
Вообще, имхо, методы нужно воспринимать как сообщения. Мы посылаем объекту сообщения, а как на них реагировать, решает сам объект. В идеале к кишкам объекта доступа быть вообще не должно, а все свои инварианты объект сохранит сам.

Да в случае со статически размещённым RECORD я бы вообще не говорил о какой-то объектной семантике. Это тупо тип данных с множеством операций. Не более, не менее.

Хм... А с каких пор ООП только про указатели?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Май, 2016 23:02 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Илья Ермаков писал(а):
ilovb писал(а):
Интерфейс - способ взаимодействия между двумя системами.
Процедура не объект и не система. Называть ее сигнатуру интерфейсом несколько натянуто.


А почему только системами? Или почему процедура не система? Условности это...
Без схоластики, интерфейс возникает там, где есть что-то кроме интерфейса (скрытое, чьи изменения не видны за неизменным интерфейсом). Т.е. как только объективно есть скрытое внутреннее устройство, так возникает и интерфейс.
В этом конкретном смысле - вполне себе интерфейс... Который может быть подинтерфейсом большего интерфейса.

У тебя установка X имеет интерфейс из 10 кабелей. А каждый кабель - свой подинтерфейс )


Да просто потому, что это общепринятое понимание этого термина.
http://technical_translator_dictionary. ... 0%B9%D1%81
https://en.wikipedia.org/wiki/Interface_(computing)

Мы имеем дело с машинами и только с машинами. Машины - это автоматы. Вот возьмем, например, кофейный автомат. На передней панели есть кнопки и индикаторы. Мы можем сообщить что-то автомату (нажать кнопку), и он может сообщить что-то нам (индикаторы мигают). Вот состав кнопок и индикаторов и есть интерфейс между мной и машиной. Причем совершенно очевидно, что панель можно делать с различным дизайном, материалом, размером и т.д. На интерфейс это никак не влияет, ибо абстракция. Благодаря этому мы и пользуемся без проблем практически любым кофейным автоматом. Далее с кофейным автоматом может быть соединен вендинговый автомат. Соединяются они, например, шиной, работающей в обе стороны. На шине реализуется протокол обмена информацией между машинами. Это тоже интерфейс.
В целом:
1) интерфейсы таки определяют взаимодействие всегда между системами;
2) интерфейсы - это как правило обмен информацией в обе стороны;
3) интерфейсы определяют по сути перечень сигналов, которые одна система может посылать другой и vice versa;
4) все остальное интерфейсом лучше не называть.

Процедура не имеет интерфейса в том же смысле, в котором не имеет его кнопка. Можно конечно натянуть сову на глобус и сказать, что де фиксация кнопки при нажатии является ее интерфейсом. Ну в каком-то смысле да... Но зачем бросаться во все тяжкие? :)

Ну и возвращаясь к изначальному... Если сказанное выше верно, то что нам следует считать уточнением интерфейса? Если я, например, поменял местами два параметра у процедуры, интерфейс изменился?
Очевидно, что нет. Гемора юзеру я добавил, но интерфейс не стал сильнее/слабее/точнее. Далее если я навесил дополнительную семантику, которая запрещает вызов процедур (кнопки стеклом закрыл), интерфейс уже понятно изменился, но стал ли он сильнее/слабее/точнее? Странным он точно стал (кнопки есть, а давить нельзя), но ради чего это делалось? В спеке на кнопки написано, что они ненажимаемые? Ну хрень ведь! :)

Давайте делать технологии более приземленными. И так все слишком сложно вокруг.

ps Меня потрындеть пробило. Не воспринимайте всерьез.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 02:16 
Модератор
Аватара пользователя

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


Да имеет она интерфейс... Т.к. реализация может быть абсолютно разная! (Вызов процедуры, в конце концов, можно рассматривать как посылку сообщения объекту процедуры в памяти :)) В Smalltalk вон вообще всё есть сообщение, не то что даже твоя кнопка )
В случае с кнопкой - если кнопка имеет сколь-нибудь сложное внутреннее устройство, то почему не говорить об интерфейсе и разных реализациях внутренних.

Цитата:
Ну и возвращаясь к изначальному... Если сказанное выше верно, то что нам следует считать уточнением интерфейса? Если я, например, поменял местами два параметра у процедуры, интерфейс изменился?

А если ты поменял штырьки в физическом интерфейсе местами?
Или поменял уровни сигналов для 0 и 1?
Какой будет ответ?
Ответ будет такой, что произошло определённое изменение на физическом уровне интерфейса (в первом случае - в конструктиве, во втором - в физическом уровне протокола). На логических уровнях интерфейс остался неизменным.
(Эталонная модель OSI, кстати, как расшифровывается? - Open System Interface. Интерфейс межсистемный, определённый многоуровнево).

Цитата:
Очевидно, что нет. Гемора юзеру я добавил, но интерфейс не стал сильнее/слабее/точнее.

Интерфейс - это вообще всё, что нужно внешнему миру знать для взаимодействия с твоей системой.
В том числе и всякие "досадные частности", не добавляющие ни силы, ни точности. Физический уровень передачи в линии... Или вот фиксация жесткого порядка параметров в процедурах ради эффективности вызова (или ради традиции - синтаксиса). В Аде можно наплевать на порядок и явно указать, какой параметр чему равен: CallProc(x => 2, y => 5, z => 6) - если не путаю...

Цитата:
Так то оно так. Вопрос в том, с чего вдруг все решили, что знают какой стороной нужно втыкать? Петр уже говорил об этом.

Я считаю, что обсуждаемая ситуация - из разряда "краевых эффектов" и "особых точек". Когда возникает такая вот досадная негладкость... Ну что ж теперь. А пытаться вылизать - ну что, вообще убирать IN\OUT? Нет, они хороши в основной части своей области применения.

Цитата:
Хм... А с каких пор ООП только про указатели?


Я давно придерживался мнения, а за последний год абсолютно укрепился, что ООП следует рассматривать как метод/механизм исключительно уровня программных артефактов. Т.е. не вкладывать в него ничего прикладнее/модельнее, чем конкретный способ соединения программных артефактов (с целью расширяемости системы - виртуализации вызова и соединения разных реализаций). Вот тупо механизм - всё.
Для любого моделирования семантики предметной области это слишком слабо, там нужно уже надстраивать другие понятия, используя ООП просто как средство удобной организации библиотеки/фрейморка, но не как способ анализа и моделирования предметки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 09:28 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
У меня об ООП совсем другое представление. Объекты - это абстрактные модели реальных явлений. Объекты имеют скрытое состояние и интерфейс входных/выходных сообщений. Т.е. я больше склоняюсь к подражанию реальному миру.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 10:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Но это будут уже другие объекты, другой инструмент, нежели языковые.

Например, этот твой объект реального мира, сущность, в веб-системе у меня представлен связанным по общему ID набором записей в нескольких таблицах, которые я называю грани, фасеты объекта - допустим, Auth_user и MSocial_person - это грани одного объекта (Условно их можно собрать в наследование, но не всегда, может быть ветвистая зависимость - это в полном смысле слова грани) - и набором XML(у меня не XML, а свой формат, но неважно, пусть скажем XML)-сообщений, которые можно посылать такой сущности, при этом единый центральный брокер найдёт сам, где, в каком модуле есть реализация алгоритма исполнения этого сообщения.
При этом ООП языковое не используется вообще - и его бы на такую семантику не хватило.
Ну т.е. оно используется как раз в смысле артефактов программирования - абстрактный объект Broker, сменяемые реализации и т.п. Но не на прикладном уровне.

В АСУ ТП у меня, опять же, объект реального мира описывается деревом фреймов с полями, к которому привязаны активности на конечных автоматах. ООП используется как основа для структур данных, но не никакого языкового класса, который бы соответствовал сущности предметной области. Потому что не хватает семантики языкового ООП (любого современного языка) для моделирования предметки. Нужно сделать свой каркас, с использованием ООП для его артефаков, а потом уже описывать предметку таким каркасом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 11:01 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Так я и не про языковое ООП, а вообще. Если средства позволяют упаковать и скрыть состояние, и при этом 2 и более таких объекта могут иметь один интерфейс, то это ООП в моем понимании. Если языковые средства позволяют это выразить, то что мешает их использовать? Вот например чего не хватает в Go для твоих задач?

Цитата:
Например, этот твой объект реального мира, сущность, в веб-системе у меня представлен связанным по общему ID набором записей в нескольких таблицах, которые я называю грани, фасеты объекта - допустим, Auth_user и MSocial_person - это грани одного объекта


Это все детали реализации и кишки. То же самое и в 1С. Если ты работаешь с этим напрямую, то это не ООП (в моем понимании). Вот если взаимодействие с такой сущностью идет только через объект или модуль с определенным интерфейсом, который не позволяет нарушить инварианты системы, то это ООП.

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

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

Вообще системы и инварианты - это большая отдельная тема, которая очень скудно раскрыта в литературе. Это наверно лучше в отдельной ветке обсуждать.

pss Да, и наследование я к ООП не отношу. Это бред, выдуманный Страуструпом etc


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 11:38 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
ilovb писал(а):
pss Да, и наследование я к ООП не отношу. Это бред, выдуманный Страуструпом etc
Наследование это всего лишь один из видов отношений в онтологии объекта. Объекты ведь не нужны сами по себе, они должны как-то соотноситься с другими объектами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 11:51 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Я таки последнее время придерживаюсь мнения, что отношения между объектами - это нечто искусственное. Видов отношений тьмы и тьмы. И выделение родственных связей объектов кажется больше решением технических проблем, чем концептуальных. Вот в Обероне расширение записей по сути реализация (одна из) общего интерфейса для группы объектов. Т.е. тупо техническая возможность в один параметр пихать разные объекты, отвечающие некоторым инвариантам. Но ведь это просто конкретная реализация. В Go это делается интерфейсами. В Lua замыканиями.

Вон даже сам Вирт в компиляторе расширения записей не использует, и делает ровно то же, но технически иначе (таблица символов).


В сухом остатке, я бы оставил концепции отношений между объектами за пределами ООП.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 14:18 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
ilovb писал(а):
Это все детали реализации и кишки. То же самое и в 1С. Если ты работаешь с этим напрямую, то это не ООП (в моем понимании). Вот если взаимодействие с такой сущностью идет только через объект или модуль с определенным интерфейсом, который не позволяет нарушить инварианты системы, то это ООП.

Нет, это не детали реализации - это логическая информационная модель, при этом не пассивная, как просто реляционная, а активная, с сообщениями в стиле SOA. Реализация - это уже какая СУБД, как технически что реализуется...
Взаимодействие в плане выполнения бизнес-транзакций идёт через кидание XML-образного (условно называю так) сообщения о необходимости исполнить некую операцию над какой-то сущностью или несколькими сущностями. Кидание идёт просто в единую точку, брокер, - и приходит ответ. А дальше уже правила в брокере определяют, в зависимости от типа сообщения и типа сущности, кто и как это будет исполнять, локально или удалённо и т.п.
Т.е. это - ещё больше ООП, чем ООП. :) По сути.

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

Цитата:
Не очень понял. Поведение конкретного объекта как-то отделено в системе от всего остального? Если нет, и в системе просто набор общих алгоритмов над СУБД, то это опять-же не ООП в моем понимании.

Отделено. Конкретные виды сущностей и сообщений обслуживают конкретные модули. Там описываются и правила по валидации самих сообщений, и правила в стиле конечных автоматов на возможность выполнения операции над сущностью в текущем состоянии (допусим, сущность "платёж" проходит цепь состояний, описывается КА), и правила прав доступа.

Цитата:
pss Да, и наследование я к ООП не отношу. Это бред, выдуманный Страуструпом etc


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

Т.е. стандартная общепринятая нагрузка термина ООП: "Для Атоса (программирования, организации кода) это слишком много, а для графа де Ла Фер (прикладной автоматизации, системной инженерии) - слишком мало".

Изжил себя термин в широком смысле. Ну вот вершины его развития: RUP - rational unified process - "мертвечина" же! Domain Driven Design Эрика Эванса - мощый целостный подход, да. Мышление верное. А потом в рамках отображения предметки на джавовские классы, все эти Object-Relation-Mapping-и и т.п. становится весьма тесно и не-очень-уклюже. И следующий шаг, который просится от его методологии - это сохраняя стиль мышления, вылезти за эти языковые рамки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 14:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
ilovb писал(а):
И выделение родственных связей объектов кажется больше решением технических проблем, чем концептуальных. Вот в Обероне расширение записей по сути реализация (одна из) общего интерфейса для группы объектов. Т.е. тупо техническая возможность в один параметр пихать разные объекты, отвечающие некоторым инвариантам.


Да! Вот и надо воспринимать языковое ООП, как и все синтаксические механизмы, тупо в духе "техническая возможность что-то как-то куда-то пихать".
Прикладная семантика тонко и деликатно обеспечивается созданием фреймворка под класс задач поверх языка. А не выражается языком.

Цитата:
В сухом остатке, я бы оставил концепции отношений между объектами за пределами ООП.

В каком-то смысле да.
Это у тебя ещё один звоночек, что надо отрезать ООП как языковые механизмы от типа-называемого-ООП-но-уже-выходящего-на-другой-уровень.

В плане тех же отношений в стандартном ООП похерена гибкость отношений, допускаемая реляционной моделью и ER-методологией. Они дадут фору ООП.
Кстати, посмотри ERIL Митькина, занятная довольно вещь: https://en.wikipedia.org/wiki/ERIL
На русский я как-то переводил: viewtopic.php?p=86047


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июнь, 2016 16:28 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
ilovb писал(а):
Я таки последнее время придерживаюсь мнения, что отношения между объектами - это нечто искусственное. Видов отношений тьмы и тьмы.
...
В сухом остатке, я бы оставил концепции отношений между объектами за пределами ООП.

Отношения между объектами, как и границы самих объектов - это предмет работы проектировщика-архитектора, который занимается формализацией всей этой мути. Математический аппарат для всего этого выдумали уже давно, ещё на заре ИТ. Только вначале компьютеры были недостаточно мощны, чтоб хорошо тянуть всю эту математику, поэтому пришлось обходиться ублюдочными решениями в виде ООП, на поле доступной тогдашним компам императивщины. Сейчас теория категорий получила современно-мощную компьютерную поддержку и даже Дейкстра хвалил Хаскель за математичность представления программы.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 17 ] 

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


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

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