Форум SAS.Планета

vdemidov писал(а):Тоесть ты хочешь сказать, что твоя версия запустится с ReadOnly носителя типа компакта или шары с ReadOnly доступом? Я так понял оно просто не запустится или метко не покажет, а sml база будет работать на ура

Ну во-первых моя версия отлично работает с SML (и даже база копируется как у тебя раньше)))))), и даже при работе с SML импортует метки из SQLite.
Во-вторых, под рид онли метками я по доброте душевной имел в виду исключительно рид онли метки. А не весь носитель, на который по идее дожны упасть например настройки программы при выходе, или последнее выделение.

Слушайте, что за разброд и шатание?
Нельзя проект делить на два стрима, в результате и САС, и САКС скатятся в сраное говно!

vdemidov, пожалуйста, объясните для начала, что конкретно не нравится в коде vasketsovа?
Почему бы все эти САКСовые фичи не включить в САС?
Если нельзя включить все, то какие можно?

Ребята, давайте жить дружно! ©

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

Давайте лучше не между собой, а вместе. И в какой же ещё теме, как не в этой?

Вы уже начали обсуждать, как делить багтрекеры. Вот именно этого мне и не хотелось бы: слишком много гемора поддерживать 2 продукта параллельно. Проще забить на оба. Всё это имеет смысл, если продукты существенно отличаются по функционалу или у них принципиально разная аудитория. Но здесь-то в чём принципиальная разница?

Что мешает запихнуть все фичи в один продукт?

-------
Название SACS весьма неудачное (читается sucks или sex), советую изменить, если не удастся всё смёржить. В help - about и других местах новое название никак не отражено, надо исправить.

Tolik писал(а):Что мешает запихнуть все фичи в один продукт?

Количество костылей и С подобных конструкций в коде vasketsov

А можно тему костылей раскрыть подробнее? Можно каждый костыль заменить на что-то расово верное?
С-подобность влияет на стабильность, производительность, удобочитаемость, что-то?

Tolik писал(а):С-подобность влияет на стабильность, производительность, удобочитаемость, что-то?

Именно на удобочитаемость и влияет, точнее на ее отсутствие.

Tolik писал(а):А можно тему костылей раскрыть подробнее? Можно каждый костыль заменить на что-то расово верное?

Ну один из самых ярких примеров. Зачем в MarkCategoryFactoryConfig, который отвечает исключительно за дефолтные параметры новых категорий, добавлять свойство DBFileName и завязвать на него использовать sqlite или нет?

Tolik писал(а):Давайте лучше не между собой, а вместе

Я ранее предельно чётко постарался отразить свою позицию. И добавить мне к ней нечего.
В её рамках никакой третейский суд и прочий всякий арбитраж ничего не изменит.
Никакие дебаты не приведут к тому, что мне будет гарантирован доступ в репозиторий, и что то, что я делаю, не будет откачано, сломано и на это будет забито.
Так что мне и правда непонятно, зачем заставлять vdemidov выступать в этой теме.

Tolik писал(а):А можно тему костылей раскрыть подробнее?

Это сильно поверхностный вопрос.
Как минимум потому что вечный рефакторинг неявно предполагает создание костылей на более ранних этапах творчества.
Правильные вопросы должны быть намного глубже (например что такое састим, что vdemidov уполномочен решать единолично).
Не говоря уже о том, что костыль вполне может оказаться вовсе не костылём (пример - "День Шакала" Форсайта).

Tolik писал(а):Можно каждый костыль заменить на что-то расово верное?

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

vdemidov писал(а):Зачем в MarkCategoryFactoryConfig, который отвечает исключительно за дефолтные параметры новых категорий, добавлять свойство DBFileName

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

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

С другой стороны - могу только приветствовать попытки запилить в инструмент нужный и востребованный функционал, даже путем ухудшения читаемости кода (бо там и так черт ногу сломит и по состоянию на сейчас). Feya-style если угодно, да - ибо рабочие инструменты (SAS) делают для того чтобы ими работать, а не любоваться на их составные части путем медитаций на рефакторинги. Считаю, что у рефакторинга должен быть самый минимальный приоритет, а если при этом в результате оного еще и отваливаются ранее работающие и нужные фичи - то такой рефакторинг вообще не нужен, ибо боль даже не во спасение фичи а вообще непонятно во что, что доставляет свежих багов + отодвигает ввод плагинов нужных фич на 2020й год даже для оптимистов, а перспективы качественных улучшений инструмента (а не красоты кода) от такого рефакторинга - весьма туманны. С точки зрения конечных пользователей, САС либо работает - либо нет, а коды и рефакторинги 99.9% юзеров до звезды. Проще перечислить по пальцам одной руки старого инвалида-столяра - скольким юзерам красота кода нужна и важна, чем скольким сотням тысяч - совершенно неинтересна...

PS: повторяю: я - не программер, и просто оставил тут свое личное оценочное суждение.

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

Тот код, реализующий SQLite-метки был невероятно сложен (для меня лично) и вести его сколь-нибудь внятную поддержку и доработку наверное только сам vasketsov и смог бы. Либо кому-то пришлось бы сперва разгребать и рефакторить его, попутно вникая в логику и только потом можно было бы говорить о поддержке. В этом случае рефакторинг мог бы занять на порядок больше времени, чем банальная реализация с нуля.
Существующий же код САСа, с большего, понятен (опять же, для меня лично), хоть кто-то там и показывает пальцем - он просто не видел кода sqlite-меток.

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