OberonCore https://forum.oberoncore.ru/ |
|
Про общеупотребимые компоненты. https://forum.oberoncore.ru/viewtopic.php?f=47&t=4403 |
Страница 1 из 5 |
Автор: | Пётр Кушнир [ Понедельник, 15 Июль, 2013 14:14 ] |
Заголовок сообщения: | Про общеупотребимые компоненты. |
Задумался тут недавно по поводу стандартной библиотеки, почитав комментарии к этому опросу http://habrahabr.ru/post/186518/. По результатам составил небольшой список того, без чего уже ничего писать не хочется (здесь не перечислены стандартные сервисы ББ, типа Text или Forms):
|
Автор: | Jordan [ Понедельник, 15 Июль, 2013 15:38 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Примеры будут, как сие использовать? |
Автор: | Иван Денисов [ Понедельник, 15 Июль, 2013 19:02 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Кроме стандартных подсистем, регулярно использую только Lib и DiaPlot. Остальные только под конкретный проект: Ctls, Sdl, FreeImage. Постоянно смотрю в документацию, на память помню мало, поэтому интерактивная справка ББ — самое оно для меня. Списки горожу каждый раз сам, давно присматриваюсь к Lists, но есть какой-то барьер. |
Автор: | Jordan [ Понедельник, 15 Июль, 2013 19:53 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Иван Денисов писал(а): Кроме стандартных подсистем, регулярно использую только Lib и DiaPlot. Остальные только под конкретный проект: Ctls, Sdl, FreeImage. Постоянно смотрю в документацию, на память помню мало, поэтому интерактивная справка ББ — самое оно для меня. Списки горожу каждый раз сам, давно присматриваюсь к Lists, но есть какой-то барьер. Барьер наверно в плане эффективности, а вдруг у меня быстрее работает. Для моей задачи нужны были 7 списков. Сначала делал ручками, копи пастом, не то. Потом решил делать объединениями + хранить указатели на первые вхождение семи структур, для ускорения добавления и поиска в списке. Потом перешёл на С++, и делаю с помощью stl. До этого думал, что свои списки быстрее и лучше. |
Автор: | Иван Кузьмицкий [ Понедельник, 15 Июль, 2013 21:03 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Jordan писал(а): Примеры будут, как сие использовать? Что вы имеете в виду?
|
Автор: | Jordan [ Понедельник, 15 Июль, 2013 21:28 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Иван Кузьмицкий писал(а): Jordan писал(а): Примеры будут, как сие использовать? Что вы имеете в виду?Описание списков, массивов(векторов) и т.д Всё, что будет входить в стандартную библиотеку. Для КП, можно сделать библиотеку exlib, которая содержит подобие stl. Главное дать программисту, только базовые конструкции типа списка, вектора, графа, стэка и т.д, что бы каждый раз не писать всё по новому. Повторное использование. |
Автор: | Иван Кузьмицкий [ Понедельник, 15 Июль, 2013 21:33 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Мне стало ещё менее понятнее Под примером обычно понимают кусок прикладного кода, демонстрирующий способы использования библиотечных функций. А то, о чём говорите вы - не примеры, а техническое задание на стандартную библиотеку. Тут до ТЗ ещё далеко, как я понимаю, ведь тред собирает опыт использования. |
Автор: | Илья Ермаков [ Понедельник, 15 Июль, 2013 23:04 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Какие-то базовые структуры для того, когда нужно хранить-работать с множеством подобъектов, типовым образом, просятся... Но то, что обычно принято делать, не нравится, вообще... Нужно что-то ещё |
Автор: | Пётр Кушнир [ Понедельник, 15 Июль, 2013 23:33 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Что, например? Я вот устав от постоянного приведения типов элементов списка в клиентском коде придумал такой способ работы со списком viewtopic.php?p=78013#p78013 Конечно, в основании всё равно список, но сам принцип работы с операциями слегка отличается от обычных итераторов. А вот совсем недавно внутрь получившегося интерфейса поместил работу с Mysql, где данные не хранятся в памяти ББ. |
Автор: | Jordan [ Четверг, 18 Июль, 2013 08:28 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Илья Ермаков писал(а): Какие-то базовые структуры для того, когда нужно хранить-работать с множеством подобъектов, типовым образом, просятся... Но то, что обычно принято делать, не нравится, вообще... Нужно что-то ещё Что конкретно? Вот именно, давно просятся. |
Автор: | Илья Ермаков [ Четверг, 18 Июль, 2013 10:13 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Мне хочется какой-то стандартизированной структуры данных, сериализуемой и интероперабельной между разными языками/платформами. Типа JSON, но он schema-free и ресурсоёмок (хотя уже полегче, чем XML). И пытаясь решать эту задачу для древовидных форматов (допускающих вложенность), я пришёл к выводу, что оно, если имеет схему, то получается сложным. Поэтому сейчас смотрю в сторону таблиц... |
Автор: | Пётр Кушнир [ Четверг, 18 Июль, 2013 11:00 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
вы про JSON Schema или совсем нет? |
Автор: | Пётр Кушнир [ Четверг, 18 Июль, 2013 12:22 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Все в отпусках, мало ответов. Jordan писал(а): Примеры будут, как сие использовать? Я сначала посчитал вас троллем, но администрация решила иначе, поэтому отвечу вам, что примеры использования обычно можно найти в составе обсуждаемой подсистемы, обычно это модули с префиксом "Obx", ну или даже "Test". Ещё можно читать документацию, в подкаталоге Docu. Обычно в опубликованных подсистемах такая имеется. Так сложилось, требование такое, вы бы знали об этом, если бы вам это было действительно интересно.
|
Автор: | Илья Ермаков [ Пятница, 19 Июль, 2013 12:54 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Пётр Кушнир писал(а): вы про JSON Schema или совсем нет? Мда? Не знал, что есть схема для JSON... Просто JSON-овские СУБД типа Mongo обычно schema-free... Как-то в XML/JSON СУБД схемы не приживаются... |
Автор: | Пётр Кушнир [ Пятница, 19 Июль, 2013 12:59 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Да, но оно пока ещё не окончательный стандарт. Я даже думал реализовать, но потом внимание переключилось. |
Автор: | Евгений Темиргалеев [ Пятница, 19 Июль, 2013 17:25 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Пётр Кушнир писал(а): Jordan писал(а): Примеры будут, как сие использовать? Я сначала посчитал вас троллем, но администрация решила иначе,... |
Автор: | Евгений Темиргалеев [ Пятница, 19 Июль, 2013 21:13 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Об "обще"употребимых компонентах, на мой взгляд, имеет смысл говорить, помятуя тематическое направление, содержащее задачи одного класса. Да и здесь субъективность может играть большую роль --- из нескольких схожих компонентов А1, А2, ..., Аn, решающих суть одну задачу, один быстрее поймет, применит (и привыкнет) к первому, другой --- к последнему. После же, по свойственной нам лени, более начинает давлеть привычка, нежели здравый смысл. И выходит у одного стандартный (для всех задач класса) --- А1, а у другого --- Аn, хотя бы по сугубой конкретике задачи и выходило наоборот (и компонентность всячески способствует замене). Экстраполировать же стандартность за пределы тематического направления и вовсе пагубно. Потому как надежда на всемогую всеобще-стандартную библиотеку непосредственно отучает человека от его главной работы --- думать, подходя к задаче со тчащнием о каждой детали. Умные люди уже давно сказали --- грамотная постановка задачи --- половина решения. Но как можно точно понять задачу, опуская детали?... Те же списки --- в одном месте могут быть так длинны, что хранить их придётся во внешней памяти, а в другом будет довольно фиксированной максимальной длины с хранением в статическом блоке памяти (в массиве, указатель = индекс). |
Автор: | Пётр Кушнир [ Пятница, 19 Июль, 2013 21:57 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Кстати, подобная идея тоже обсуждалась, формировать не "стандартные компоненты вообще", а например "стандартные компоненты для SQL", "стандартные компоненты для web" и так далее. Проблем несколько, во-первых, списки компонентов будут раздельные, а компоненты хорошо бы привести хотя бы к состоянию отсутствия дублей функциональности в каждом городе необъятной Родины. И вторая проблема это наличие приложений с различными функциями, что приводит к необходимости того, чтобы эти списки компонентов могли между собой сочетаться. |
Автор: | Jordan [ Пятница, 19 Июль, 2013 22:30 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Евгений Темиргалеев писал(а): Экстраполировать же стандартность за пределы тематического направления и вовсе пагубно. Потому как надежда на всемогую всеобще-стандартную библиотеку непосредственно отучает человека от его главной работы --- думать, подходя к задаче со тчащнием о каждой детали. Умные люди уже давно сказали --- грамотная постановка задачи --- половина решения. Но как можно точно понять задачу, опуская детали?... Честно, и согласен, но в тоже время нет. Задач, много, но много ли задач, которым нужна тонкая настройка? То есть пишу программу, в пары мест нужно, что то своё более заточенное под задачу, а в остальных 80% кода, стандартные решения подходят идеально и естественно лучше всё остальное делать стандартным способом. Евгений Темиргалеев писал(а): Те же списки --- в одном месте могут быть так длинны, что хранить их придётся во внешней памяти, а в другом будет довольно фиксированной максимальной длины с хранением в статическом блоке памяти (в массиве, указатель = индекс). Именно, где нужно, будет своя реализация, а в остальном общее решение. Пётр Кушнир писал(а): Кстати, эта идея тоже обсуждалась, формировать не "стандартные компоненты вообще", а например "стандартные компоненты для SQL", "стандартные компоненты для web" и так далее. Это интересно, вы не могли бы написать свои соображения по этому поводу? Пётр Кушнир писал(а): Я сначала посчитал вас троллем Уверяю вас, я не троль. Я не зелёный, и не живу в лесу. |
Автор: | Иван Кузьмицкий [ Пятница, 19 Июль, 2013 22:57 ] |
Заголовок сообщения: | Re: Про общеупотребимые компоненты. |
Jordan писал(а): Задач, много, но много ли задач, которым нужна тонкая настройка? То есть пишу программу, в пары мест нужно, что то своё более заточенное под задачу, а в остальных 80% кода, стандартные решения подходят идеально и естественно лучше всё остальное делать стандартным способом Разрешите подписаться. Чем писать собственные, к примеру, сортировки, лучше взять подходящую готовую из библиотеки и получить работающий прототип системы. Если в дальнейшем прижмёт с оптимизацией, можно потратиться на переписывание. К тому же, стандартные решения (подходящие для 80-90 процентов случаев), как правило, и более безопасны - потому что комьюнити уже успело наступить на все возможные грабли.
|
Страница 1 из 5 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |