SACS: Another Clone of SAS

[Tolik]

Так к чему мы в результате приходим?
Есть sas-team, которая поддерживает SAS.Planet через багтрекер, и есть vasketsov, который поддерживает SACS?

Если, например, найден баг в обоих проектах и в SAS его фиксит zed, что произойдёт в SACS:
1. zed будет его фиксить и там тоже (делать двойную работу, разбираясь в адской смеси)
2. vasketsov будет брать фикс в репозитории sas-team и внедрять его в свой код (который, быть может, уже настолько отличается, что простой коммит не прокатит)
3. в SACS баг останется

[zed]

Есть sas-team, которая поддерживает SAS.Planet через багтрекер, и есть vasketsov, который поддерживает SACS?

Ну, выходит что - да. Пока/если не появится sacs-team.

Если, например, найден баг в обоих проектах и в SAS его фиксит zed, что произойдёт в SACS:

1. Не, в адскую смесь я не хочу.
2,3 - на усмотрение vasketsov-а

[zed]

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

Вот-вот. Проблема и вся эта ситуация из-за того, что кто-то единолично, без объяснения причин (соответственно, не давая возможности устранить эту причину сообща) принимает радикальные решения. Нет чтобы по нормальному сказать что не так, что лучше переделать, а что лучше вообще не делать/выбросить. С людьми надо разговаривать, они мыслей читать не умеют. И не нужно юзать диктаторские приёмчики в open-source. Не красиво!

[vasketsov]

Надо понимать, что рефакторинг это вообще-то важная часть разработки и нельзя говорить, что он не нужен

Верно. Это лекарство для проекта. Как и любое другое - назначается не постоянно, а дозировано, причём с учётом побочных эффектов, иначе жизни не будет.

А если забить на рефокторинг, то в конце концов может получиться такая адская смесь в коде, что реально добавить туда что-то новое будет практически невозможно

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

Тот код, реализующий SQLite-метки был невероятно сложен

Ребята, я вас умоляю. Одна БД вместо двух + вместо родных объектов структуры с методами (там где не надо наследование и можно разместить их на стеке - это и компактнее, и быстрее работает, важные отличия только в конструкторах-деструкторах) + голый SQL без датасетов - и всё. Проще некуда. Любая реализация датасета только снаружи просто выглядит. А по размеру и скорости безбожно сольёт такой "плоской" реализации. В случае TileStorage_DBMS - это 700 кил с датасетами против 200 кил с копейками - без них.

просто не видел кода sqlite-меток

Код доступен. Код TileStorage_DBMS (который с моей точки зрения существенно сложнее в итоговом варианте) - тоже.
Возможно тут сыграло роль то, что ты отчётливо понимаешь, что делают те же самые функции в DLL, что и в сасе, и поэтому проще. А в случае меток в SQLite аналога в сасе не было.
Впрочем как я уже писал, с глобальной точки зрения это не вопрос code review или арбитража.

Вот из-за таких вот вопросов реализации и вытекает жизненная необходимость плагинов

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

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

[vasketsov]

Есть sas-team, которая поддерживает SAS.Planet через багтрекер, и есть vasketsov, который поддерживает SACS?

Не вижу оснований нас противопоставлять (если конечно это вкладывалось).
Сейчас например сас работает с моими DLL-ями, а моя версия - с DLL-ями от zed-а.
зы. Желающие даже могут называть их плагинами )))
ззы. Сейчас не 90-е года, так что с контролем версий всё куда проще, чем кажется.

делать двойную работу, разбираясь в адской смеси

Основная цель "отпочковки" - как раз ИСКЛЮЧЕНИЕ двойной работы.
В этом смысле совершенно непринципиально, где править общий баг, важно чтобы "невинные" кодеры делали это ОДИН раз.
Баги - они как правило весьма локальны, глобальные баги, требующие переделки почти всего, вылезают обычно сразу.
И с некоторой вероятностью патч пролетит между репозиториями в любом направлении. Хотя конечно в конкретном случае могут быть особенности.
Например может потребоваться дополнительная реализация в другом месте.

vasketsov будет брать фикс в репозитории sas-team и внедрять его в свой код (который, быть может, уже настолько отличается, что простой коммит не прокатит)

Чтобы не прокатил простой коммит - код должен отличаться в локальном контексте. Но даже в этом случае остаётся вариант копирования куска кода руками (что раз в 10 быстрее, чем через патч, если проект и репозиторий уже открыт).

[zed]

Возможно тут сыграло роль то, что ты отчётливо понимаешь, что делают те же самые функции в DLL, что и в сасе, и поэтому проще. А в случае меток в SQLite аналога в сасе не было.

Да, скорее всего. В метки я вообще особо не заглядывал, поэтому глаза слегка и округлились, увидев это

[Parasite]

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

Я не говорил что он не нужен ВООБЩЕ - я говорил что он не нужен тогда, когда после него становится хуже чем было до, и на это к тому же частенько дается ответ в стиле "А мне отломанное не нужно - хочешь, чини сам и присылай коммит". Ну вон прислал васкецов коммит на метки - и...?

Так-то я ничего против улучшения кода как такового не имею - мне просто ранее работавший\отлаженный, а ныне отломанный функционал не нравится как таковой. Это относится в равной мере как в вдемидову (из показательного - отломка "пробок", чинить пришлось всем миром и через грабли), так и васкецову (отломанное определение low-res DG). Это то, что вылазило предо мной лично за последние время. Другие, я думаю, могут добавить куда больше в список.

И ладно бы ответы на репорты бага были "У блин, точно, щас починю вне очереди!" - ан нет... Невольно опять вспоминается фей с корявым кодом - но чинящий все что требуется, и в первую очередь - последствия своих же отломок.

[zed]

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

Варианты:
ex.SAS.Planet
eSAS.Planet
EXSAS.Planet
SAS.Planet.Ext

[zed]

Ночнушки: https://bitbucket.org/vasketsov/vsasas/downloads

[Tolik]

Надо изменить help-about, заголовок окна, сплэш-скрин. И имя экзешника, пожалуй.
Должно быть видно, что это продукт не sas_team (а только написан на базе него).

Дело не в копирайте (или не только в нём). Кто-нибудь обнаружит баг и откроет багрепорт на САС, разбирайся потом, какой там на самом деле продукт и релиз.

Кстати, сразу вопрос: когда это произойдёт, что делать: сразу закрывать или таки будет сделан отдельный багтрекер?