EvilBeaver
реализовать для совместимости с 1С кодом функцию ЗначениеИзСтрокиВнутр и обратную
Originally reported by: Alexey Lustin (Bitbucket: allustin, GitHub: allustin)
ЗначениеИзСтрокиВнутр (ValueFromStringInternal) Синтаксис:
ЗначениеИзСтрокиВнутр(<Строка>) Параметры:
<Строка> (обязательный)
Тип: Строка. Системное представление значения в строковом виде. Возвращаемое значение:
Тип: Произвольный. Значение, полученное из строкового системного представления. Описание:
Преобразует значение из строкового системного представления во внутреннее.
и по аналогии
ЗначениеВСтрокуВнутр (ValueToStringInternal) Синтаксис:
ЗначениеВСтрокуВнутр(<Значение>) Параметры:
<Значение> (обязательный)
Тип: Произвольный. Преобразуемое значение
- Bitbucket: https://bitbucket.org/EvilBeaver/1script/issue/85
Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):
Я не холивара хотел - я хотел некоего поведения при копипасте 1С-ного кода в скрипты
Пусть хотя-бы скрипт при компиляции обрабатывая неизвестную функцию ЗначениеИзСтрокиВнутр/ВСтрокуВнутр что-нибудь говорит отличное от "Неизвестный литерал". Например "Error - использование внутренней сериализации 1С платформы в скриптах запрещено, аналог - <что-то>"
Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):
@awa15, для меня это сложнее, хоть с доводами я и согласен.
Original comment by Валерий Агеев (Bitbucket: awa15, GitHub: awa15):
Это, безусловно, холиварная тема. Для одних важнее читабельность кода, для других производительность. Но не суть. Я только хотел сказать, что совместимость сериализации с 1С немного труднее в реализации, имхо, но в будущем будет вызывать меньше проблем при портировании кода из 1С. В конечном итоге, для CLR-сериализации можно реализовать и отдельные функции, не совместимые с 1С. Все, что для этого надо, прописать GUID типов 1С в движке и реализовать для каждого типа несложные методы сериализации и десериализации.
Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):
Имхо, это не трюки, это адские костыли. Я сторонник того, чтобы код отражал намерения автора. Эта свистопляска вокруг сериализованных строк меня удручает. Имхо, я бы такое разрешал делать только если бы мы делали Higload сервис обработки строк на 1С и выжимали бы всю возможную производительность. Сдается мне, такого никто не делает. Код должен быть в первую очередь читабельным.
Original comment by Валерий Агеев (Bitbucket: awa15, GitHub: awa15):
Иногда функции ЗначениеВСтрокуВнутр и ЗначениеИзСтрокиВнутр используют для всяких трюков типа такого http://infostart.ru/public/71130/#Pro_bystrye_massivy При этом, кмк, сделать сериализацию совместимой с 1С не так сложно. По большому счету нужны сериализация примитивных типов, коллекций (Список значений, Таблица значений, Дерево значений, Массив) и системных перечислений. Зато возможность сделать в 1С ЗначениеВФайл какой-нибудь ТЗ, а в скрипте ЗначениеИзФайла может пригодиться.
Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):
Да - еще раз пересмотрел код и свой и чужой.
Функции в основном используются для служебных целей, и в основном для ссылочных типов объектов базы данных ;-)
Поэтому видимо нужно просто использовать штатную сериализацию CLR. Она же все равно понадобится скорее всего.
Original comment by Sergey Batanov (Bitbucket: dmpas, GitHub: dmpas):
Думаю, совместимость с 1С тут не нужна совершенно. Если прочитать примечание к этим функциям:
Примечание:
Строковое представление данных имеет специальный системный формат, использующий идентификацию данных внутри одной информационной базы.
то слова "внутри одной информационной базы" как бы намекают, что из-вне значения приходить не должны.
Для обмена с 1С лучше всё-таки использовать какую-нибудь сериализацию.
Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):
Предлагаю обсудить совместимость получаемых строк с 1С. Т.е. насколько важно отправлять полученную строку в платформу? Если так, то вопрос серьезный, если нет - то фигня делов, можно использовать штатную сериализацию CLR.
@EvilBeaver в любом случае совместимость с 1С буду рассматривать в последнюю очередь. Для начала попробую посмотреть родную .NET-овскую сериализацию, а там уж как пойдёт.