Собственно давно пытался сформулировать идею как можно навести порядок конфах 1с, формулирую:

Для объекта метаданных "Подсистема" добавляем 2 модуля (где можно писать текст), модули имеют фиксированную настройку Клиент/Сервер и пользовательские настройки "Привелигерованый" и "Вызов сервера". Еще можно добавить реквизит "Версия" но не обязательно его можно сделать через функцию
1. СерверныйИнтерфейс  
2. КлиентскийИнтерфейс

все процедуры и функции описные в них автоматически являются экспортными, кроме того каждая подсистема автоматически наследует все имена из подчиненных подсистем, но при этом в подсистеме можно переопределить процедуру подчиненной подсистема (классическое наследование)

далее:
в каждой подсистеме можно создавать произвольное число модулей, но процедуры этих модулей видны только описанных ранее 2х интерфейсных модулях (и вышестоящих интерфейсных модулях).
Разумеется имя подсистемы верхнего уровня не должно конфликтовать с


как это будет выглядеть на примере:

подсистемы
Библиотека
  СтроковыеФункции (здесь описываем функцию "Ф1" которая использует функцию из НЕ интерфейсного модуля подсистемы "Переопределяемые.ФункцияРасчетаФ1()")
  РаботаСМассивами
  ....


в простом коде будут доступны следующие конструкции

Библиотека.Ф1()
Библиотека.СтроковыеФункции.Ф1()

ФункцияРасчетаФ1() - будет не доступна.



Критикуйте ....

(0) "но при этом в подсистеме можно переопределить процедуру подчиненной подсистема" - с наследованием будет мрак: разбираться почему процедура с одним с тем же названием отрабатывает по-разному.
Общего модуля "МодульПодсистемыИКС" - вполне достаточно.

(0) > Критикуйте ....

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

(1) >>>наследованием будет мрак: разбираться почему процедура с одним с тем же названием отрабатывает по-разному.

почему? во первых есть отладчик, во вторых во взрослых языках для обращения к вышестоящей по наследованию процедуре используют что-то типа this.f1()

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


я-бы вообще сделал что-то типа (Банк и Касса это разные подсистемы, а РКО это один документ который есть в обоих подсистемах)

Банк.Документы.РКО.СоздатьОбъект() - выполняется обработчик заполнения документ а потом из подсистемы Банк
Касса.Документы.РКО.СоздатьОбъект() - а тут поле обработчика документа выполняется уже свой обработчик.

тем самым все становится намного более "адаптивно"

(2) они читают мисту, и иногда воруют идеи. Пусть и эту своруют :)

Давайте начнем пожалуй с типизации сплошь и повсюду. Как ты говоришь "Во взрослых языках" это первоочередное.

Сообщение компилятора "Ошибка преобразования типов"... Ну детский сад.

(3) Не врубаюсь, зачем "Банк.Документы.РКО.СоздатьОбъект()". Сейчас есть единая точка входа для создания документа - процедура заполнить в модуле документа. Зачем нужна подобная конструкция?

(5) типизация - это огромная работа, полная переделка платформы, а сабж - относительно небольшая доделка...

Допустим, есть объекты, которые входят в состав нескольких подсистем. Какой смысл в таком случае у этих новых модулей?

(0) И что мешает это сделать сейчас? Пишешь как тебе нравится/удобно, потом компилируешь все что написал на машину 1С. Если понравится не только тебе то лет через 5 это будет в платформе. Если же нежизнеспособная фигня - то и критиковать не придется

не надо, можно просто взять модуь и поместить его в подсистему.

А я хочу чтоб в типовых бардак в коде уменьшился.
Чем больше возможностей бардак сделать - тем больше его будет.
Замечали, что примерно одинаковый функционал разбросан по разным модулям и написан в разных стилях ? Потому что разработчики вендора не всегда дружат друг с другом.
Особенно, когда отвечают за различные блоки - бухгалтерия, зарплата, производство, торговля, CRM.
Развитие системы хорошо, но без стандартизации - плохо.

(0) А что это поменяет, кроме необходимости задублировать заголовочные строки в модулях библиотеки?
"Библиотека.Раздел1.Ф1()"
"БиблиотекаРаздел1.Ф1()"

"Библиотека.Ф1()" конечно аккуратнее но тогда для больших подсистем там будет свалка

Мдаа...

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

Тогда и искать и дружить будет проще в разы проще

(12) дублировать ничего не придется, разве что вызовы клиент+сервер

вуместо нормального ООП люди хотят какую-то дичь

"Привелигерованый", ага.

(5)(15) на партнерском семинаре в кратце показывали прототип нового языка 1С и в нем сделали строгую типизацию переменных и еще новые объекты Структуры и Перечисления по подобию классов в ООП. Там пока все зародыше, но глядишь в 1С 9 и дождемся ООП.

(17) На type-script? Или go какой-нибудь?
ИЛи свой велосипед?

(18) свой конечно, чтоб 1сники не убежали в теплые края

типизацию кстати, можно сделать необязательную
Ну и режим стрикт конечно же

(0)Подсистемы - это интерфейсная сущность; для функциональной сущности есть общие модули. Все логично на мой взгляд в 1с.

(21) чувак хочет namespace'ы

(22) круто конечно, но 1с не может определиться в каких  модулях что должно лежать, а теперь надо еще будет по наймспейсам раскидывать.
А простым смертным только им успевай, что доработки переписывать

(0) Хорошая идея. Но что мешает создать общий модуль Подсистема_Модуль_Клиентский? и т.д.
Только лень?

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

(25) ну так подсистемы же

(24) я хочу иметь приватную видимость модулей внутри маленькой интерфейсной части.

Общими модулями этого не добиться. Да и потом Вы видели сколько общих модулей в типовой? поди найди где там закопан нужный тебе функционал...

а так все будет разбито по разделам (подсистемам)

(27) > поди найди где там закопан нужный тебе функционал

Так весь сыр-бор из за этого, что-ли?
Я тя умоляю, 1Сники и на объектах сделают так, что хрен что найдешь.

(26) Нет, это другое. В случае с подсистемами установка фильтра: сдвиг мыши на кнопку в стороне; нажатие кнопки; поиск нужной подсистемы; установка флага; нажатие кнопки "Установить".
Группы: нажать "плюс" в том месте, где находишься.

При регулярном поиске сильно убыстряет. При нерегулярном тоже проще. Минус: ограничено конкретной областью.

(27) Так все запутаются. Можешь завести обработку "БиблиотекаПодсистемыХХХ". У обработки есть модуль объекта, модуль менеджера и могут быть формы и команды со своими модулями. Модулей завались!

(29) только нужно будет вспомнить для начала в какой группе искать.
А групп будет - мама не горюй

(31) Так и для подсистем то же самое. Вспоминать, как называется подсистема. Сделать иерархический режим просмотра опциональным.

С клавиатуры "развернул/это не здесь/свернул/сдвиг вниз" быстрее, чем отбирать по подсистемам. Вообще сборище объектов более, чем на один экран - плохо.

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

Да все классно с 1с, ниё не надо, даже к уродским UI УФ уже привык как к родным...

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

А так — Как сократить количество модулей? Добавить новые!!) ага...

Ещё отбор по подсистеме в конфигураторе желаю освоить автору. И поиск с отбором, чтобы искать нужный "функционал".

И да, когда уже будет нормальное ООП!!??)))

(36) > когда уже будет нормальное ООП

А потом @96edv разразится речью, что опять не понимает, что эти одинэсники наворотили, не поймешь что где лежит в иерархии, и вообще срочно нужны интерфейсы (:

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

Как было хорошо в 7.7 всего один глобальный модуль и весь говнокод как на ладони.
Только забыли еще ограничение на его длину жесткое ввести, чтобы разрабы учились лучше писать.

А вот видимость только внутри подсистем было бы прикольно кстати, некие аля "пространства имен".
Можно будет сделать что подсистемы скопировал/вставил и оно работает в другой конфе.

(38) да и на партнерке такие решения не принимаются. такие решения принимаются в тайном кабинете 1с. доступ туда имеют лишь избранные

(39) они анонсировали в телеграмм канале аналог пространства имен по подсистемам.
Правда оно будет только в ЕДТ.
Говорят будет бомба.
(40) По факту та же Миста, только за ИТС)

(41) но когда говорят будут бомба - скорее всего бомбить будут пуканы у партнёров, а то, что имелось ввиду.

(42) а не то что имелось ввиду, опечатку поправил

(41) Что за телеграм-канал? Адрес, явки, пароли? )

https://t.me/edt1c
https://t.me/ssl1c
В каком то из 2х. Они конечно скатились в говно, но на старте и сейчас весьма изредка инсайдик бывают

На той неделе были например фото с какого то семинара, там 1с представил свой прототип скриптовый машины общего назначения, аналог 1Sscript. И очень знатно побурлели говна.