Вход | Регистрация
    1  2  3  4  5  6  7  8  9  10  11   

Конкретные вопросы по lsFusion

Ø [длинная ветка, 14.10.19 - 21:06]
Конкретные вопросы по lsFusion
Я
   Bro
 
06.10.19 - 20:21
Здесь только вопросы по lsFusion, без оценок и срача, что в сторону lsFusion, что в сторону 1С. Кто будет начинать того будут блокировать.
   _DAle_
 
801 - 13.10.19 - 22:25
(479)  Попробуйте включить в настроках проекта: Settings | Preferences | Editor | File Encodings | Transparent native-to-ascii conversion.
   Лефмихалыч
 
802 - 13.10.19 - 22:25
(797) судя по (799), пользуясь метафорой дырявых ящиков, дырку не в ящике сверлить надо, а в полке. И не в той, на которой ящики стоят, а в какой-то второй и там над дырочкой бирочка, по которой ты потом найдешь ящик, которому дырка принадлежит.
   Ещё1
 
803 - 13.10.19 - 22:27
(796) Нет, у вас в приложении будет одно свойство Остатки с тремя параметрами: Организация, Склад, Товар. Типа такого:
quantity = DATA NUMERIC[10,3] (Organization, Stock, Sku);
   НиколаевГ
 
804 - 13.10.19 - 22:32
(803) В приложении понятно, я про БД вообще-то спрашивал. Получается, я должен объявить столько различных свойств, сколько комбинаций параметров, по которым я хочу получить остатки?
   Лефмихалыч
 
805 - 13.10.19 - 22:35
Ёооолкин дрын!!! Так эти свойства - это свойства ПРИЛОЖЕНИЯ, а не каких-то объектов?! Так это вот оно почему «структура зависит от того, на чём ты стоишь»! Потому, что структура есть только у одного объекта - у приложения (ну, конфигурации в наших терминах).
Так штоле?

КиануРивз.жпг
   НиколаевГ
 
806 - 13.10.19 - 22:38
(805) Ну я же говорю, не умеют фузиновцы нормально объяснять. Или не хотят, так как им только хайп нужен, а не продвижение своей платформы...
   НиколаевГ
 
807 - 13.10.19 - 22:41
(805) Приложение состоит из модулей, то есть свойства модуля, получается?
   Лефмихалыч
 
808 - 13.10.19 - 22:41
Это чо, это я угадал что ли?! Я вообще-то хотел ядовито пошутить, доведя сарказм до экстремума...
Нет, правда что ли? Я это не пошутил, а угадал?
   Ещё1
 
809 - 13.10.19 - 22:43
(798) > если я захочу остаток по товару без учета склада, я смогу вызвать in(Sku)?
Если вы зададите остаток как
quantity = DATA NUMERIC[10,3] (Organization, Stock, Sku);
то для получения всех остатков по всем организациям и складам для конкретного товара надо использовать такое свойство:
quantitySku(Sku sku) = GROUP SUM quantity(Organization o, Stock s, sku);
(возможно я не прав, тогда пусть меня подправят).
   H A D G E H O G s
 
810 - 13.10.19 - 22:44
(808) Я правильно понимаю, что ты - сам ты, возишься с этой бабуйней в вечер воскресенья?
   Лефмихалыч
 
811 - 13.10.19 - 22:44
У этого состояния сознания, в котором такое выдумывают, должен быть отдельный номер в МКБ


Серьезно. Не здоровая петрушка какая-то
   Ещё1
 
812 - 13.10.19 - 22:46
(809) Да, и учитывая, что в языке можно писать свойства с одинаковыми названиями, но разными параметрами, его можно записать как просто quantity:
quantity(Sku sku) = GROUP SUM quantity(Organization o, Stock s, sku);
   Лефмихалыч
 
813 - 13.10.19 - 22:47
(810) я тут только в теоретических основах разобраться пытаюсь. Руками это трогать за живое меня, естественно, ничего не заставит.



Я скорее руки отгрызу себе накуй
   НиколаевГ
 
814 - 13.10.19 - 22:48
(809) А это достаточно забавно. Жаль, сами фузиновцы свои преимущества не в состоянии объяснить :(
   H A D G E H O G s
 
815 - 13.10.19 - 22:50
Всем, убившим невозвратные часы своей жизни, посвящается
The most loneliest day of your life

https://youtu.be/IvoqxErkpgM
   H A D G E H O G s
 
816 - 13.10.19 - 22:52
(813) А я вот сейчас буду катать с женой Starcraft2.
   Ещё1
 
817 - 13.10.19 - 22:52
(801) Бинго!
   НиколаевГ
 
818 - 13.10.19 - 22:52
(815) Мы просто пытаемся постичь дзен...
   Лефмихалыч
 
819 - 13.10.19 - 22:55
(816) и в чем принципиальная разница?
   Ещё1
 
820 - 13.10.19 - 23:00
(804) Если задать остатки через свойство как в (803), у вас в БД будет лежать 1 таблица с тремя ключевыми полями, и одним полем типа NUMERIC[10,3]. А способов доступа к данным в lsFusion - вагон и тележка. Я их сам ещё все не знаю. Один из способов я показал в (812)
   _DAle_
 
821 - 13.10.19 - 23:07
(797) Я опять не совсем понял, что имеется ввиду (первое мое предположение, видимо, оказалось неверным).

Давайте начнем с того, что если у нас есть два свойства
selected = DATA BOOLEAN (Item)
selected = DATA BOOLEAN (Sku)
То это два разных свойства. Представим ситуацию, что это у нас единственные selected в проекте, они объявлены в одном пространстве имен, и классы Item и Sku никак друг с другом не связаны с помощью наследования.

Теперь, если мы обращаемся в некотором коде к selected(object), то произойдет следующее:
1. Если object является объектом класса Item (это в частности означает, что object может быть объектом класса, который унаследован от Item), то будет выбрано первое свойство
2. Если object является объектом класса Sku, то - второе.
3. Если object является и объектом класса Item, и объектом класса Sku (такое может быть при множественном наследовании), будет ошибка, чтобы ее обойти можно будет указать явно класс при вызове: selected[Item](object).
4. Если объект не является ни объектом класса Item, ни объктом класса Sku, то вызываемое свойство будет не найдено.
   _DAle_
 
822 - 13.10.19 - 23:17
(792) Все вроде бы круто, кроме одного но: все-таки у нас свойства не принадлежат классам. Принадлежность свойств классам - это и есть инкапсуляция в одном из своих определений (объединение данных и методов работы с ними). В нашей модели есть существенное отличие от классического ООП -
инкапсуляции у нас нет, поэтому свойства вроде quantity(Document, Store, Sku) не принадлежат в lsfusion никакому классу. Такой подход позволяет, например, реализовывать множественный полиморфизм (multiple dispatch) - это то, что в языках вроде Java реализуется для полиморфизма по двум параметрам (double dispatch) с помощью паттерна проектирования Visitor, а для трех и более вообще будет все печально. Но я предлагаю не лезть пока в такие дебри, а просто обратить внимание на тот факт, что в lsfusion все-таки свойства первичны, а классы вторичны, хоть это и, возможно, непросто понять.
   Лефмихалыч
 
823 - 13.10.19 - 23:20
Эти ваши хвалёные свойства- это тупо глобальные переменные. Отсюда и все ваши победные реляции на тему производительности. Смешно.
   _DAle_
 
824 - 13.10.19 - 23:22
(805) Приложение собирается из модулей. Внутри каждого модуля видны только те элементы, которые находятся во всех зависимых модулях. То есть тех, которые перечислены в блоке REQUIRE, и далее рекурсивно. То есть, если вы создали новый модуль, в нем свойство selected, модуль зависит только от модуля System, и второй новый модуль, зависящий только от System, то в этом втором модуле в ыникак не будете видеть свойство selected из первого.
   Лефмихалыч
 
825 - 13.10.19 - 23:24
(824) да. Это все уже не интересно. Удачи вам.
   _DAle_
 
826 - 13.10.19 - 23:24
(807) Да, в принципе, свойства модуля. Видимость их будет зависеть от того, виден ли модуль по зависимостям из места вызова. Ну и поверх модулей еще есть логика пространств имен.
   НиколаевГ
 
827 - 13.10.19 - 23:25
(822) О, у вас, вроде, получается объяснять. Может, вам лучше статьи писать о парадигме, а не Bro, он вообще не клиенториентированный какой-то.
   Asmody
 
828 - 13.10.19 - 23:34
(811) Не, ну это все очень круто как дипломная или даже кандидатская работа. "Только в жизни нашей все иначе..."
   _DAle_
 
829 - 13.10.19 - 23:35
(823) Они может и глобальные в плане видимости из модуля, который подключает модуль с местом объявления, но они принадлежат какому-то пространству имен, которые служат для разрешения конфликтов по именам идля локализации.

>Отсюда и все ваши победные реляции на тему производительности. Смешно.

Да нет, это вообще никак не связано. Язык - это всего лишь описание логики, код на языке один раз интерпретируется на старте аппликейшен сервера и в общем-то все, больше никогда к исходным файлам сервер не обращается.
   Asmody
 
830 - 13.10.19 - 23:38
(821) опять не то.
Я в своем модуле написал
selected = DATA LOCAL BOOLEAN (Item);
Реализовал какую-то логику.

Потом автор объекта через месяц в модуле объекта написал:
selected = DATA DATE (Item);

Что будет с логикой в моём модуле?
 
 Рекламное место пустует
   Ещё1
 
831 - 13.10.19 - 23:39
(822) > свойства вроде quantity(Document, Store, Sku) не принадлежат в lsfusion никакому классу.
Тогда у людей снова возникает естественный вопрос: но это же свойство, и оно обязано чему-то принадлежать.
https://ru.wikipedia.org/wiki/Свойство_(значения)
Тогда предлагаю вам такое объяснение, тоже в духе ООП: свойство quantity в нашем примере является свойством суперпозиции классов Document, Store и Sku. Т.е. это не свойство каждого конкретного класса, а некоего не заданного явно суперкласса, который объединяет всех их вместе.
   Asmody
 
832 - 13.10.19 - 23:42
(831) Это функция на декартовом произведении множеств Document, Store и Sku
   НиколаевГ
 
833 - 13.10.19 - 23:43
(831) Плохое объяснение. Вы этим поднимаете уровень абстракции сверх необходимого.
   Ещё1
 
834 - 13.10.19 - 23:47
(832) Да, это в духе ФП. Тогда почему вы их назвали свойствами, а не функциями?
(833) Вполне нормальное объяснение. Есть классы Организация, Склад и Товар. У каждого из них по отдельности нет свойства Количество в бизнес-логике нашего приложения. Но если мы объединяем их вместе, у их объединения появляются новые свойства, и в частности свойство "количество товара на складе указанной организации".
   _DAle_
 
835 - 13.10.19 - 23:48
(830) Ок. Тогда я все уже описал в своем самом первом ответе (626). Вы видите какое-то несоотвествие ответа с вопросом?
   НиколаевГ
 
836 - 13.10.19 - 23:51
(834) Так нет же никакого суперкласса, есть функция модуля с параметрами-классами, и кое-что ещё. Вот теперь осталось выяснить, что скрывается за "кое-что",
   _DAle_
 
837 - 13.10.19 - 23:54
(831) На мой взгляд то, что вы называете свойством, вообще говоря, далеко не везде называется свойством, в каком-то языке - это поле (field), в каком-то дата-член (data member в с++). Ну и почему свойство не может быть свойством пары, тройки, сотни классов? Мы просто не придумали лучший термин.
   _DAle_
 
838 - 13.10.19 - 23:57
(834) Почему не назвали функциями? Уже не помню, может завтра вспомним :)
   НиколаевГ
 
839 - 14.10.19 - 00:00
(837) Вы придумали - так теперь объясните нам, непонятливым, что же это такое на самом деле.
   _DAle_
 
840 - 14.10.19 - 00:11
(839) Если своими словами и на пальцах, то это просто именованные функции, как в математике. Которые описываются с помощью операторов, только кроме обычных арифметических операторов (+, -, /, *), логических (AND, OR, NOT), сравнения (==, !=, <, >, >=, <=) есть еще операторы, близкие к операторам из языков программирования и SQL (IF ... THEN ... ELSE, WHILE ... DO, DATA, GROUP, RECURSION и т.д., и т.п.).
Если же проводить какую-то аналогию с ООП-языками программирования, то это термин объединяющий свойства и методы класса, но только те методы, которые не изменяют состояние системы, а занимаются чистым вычислением (получением из объектов, переданных в качестве параметров, некоторого значения).
   Ещё1
 
841 - 14.10.19 - 00:12
(837) > почему свойство не может быть свойством пары, тройки, сотни классов?
Действительно, почему? Именно это я и предложил в (831)
Если не нравится термин "незаданный явно суперкласс", можете назвать их набором классов. Т.е. получится свойство принадлежит набору классов, указанных в его определении.
   Ещё1
 
842 - 14.10.19 - 00:14
(841) В духе ООП доступ к свойству такого набора через "." был бы такого вида:
(Organization, Store, Sku).quantity
   НиколаевГ
 
843 - 14.10.19 - 00:16
(840) Так, через свойства мы конкретные объекты классов, переданных в качестве параметров, изменить не можем?
   _DAle_
 
844 - 14.10.19 - 00:20
(842) Да, это упорядоченный набор классов получается. В принципе, мы обсуждали внутри (да и вроде уже и на хабре, и на мисте) возможность добавления такого синтаксиса через точку. Но он конфликтует с существующим синтаксисом и, лично мое мнение, эта штука не так важна сейчас, чтобы либо как-то умудряться подружить такой синтаксис с пространствами имен, либо еще и менять потом синтаксис обращения с помощью пространства имен и терять обратную совместимость.
   _DAle_
 
845 - 14.10.19 - 00:23
(843) Да, свойства вообще ничего менять не могут. За логику изменений отвечают у нас действия. Они из себя представляют вполне привычные императивные куски кода, с последовательностью выполнения. Именно они похожи на функции из языков программирования.
   _DAle_
 
846 - 14.10.19 - 00:25
(845) Поправочка: ...из императивных языков программирования.
   Ещё1
 
847 - 14.10.19 - 00:30
(844) OK, пришли к согласию. Да, кто-то из ваших писал здесь, что запись через точку рассматривается. И да, получается конфликт с записью пространства имён. В духе ФП пространство имён должно было записываться не через точку, а как-то так: MyClass(Namespace), что эквивалентно в ООП: Namespace.MyClass.

(843) Объяснение с позиции ООП:  Используя действия, в lsFusion можно менять значение свойства класса либо набора классов, указанного в определении этого свойства.
   _DAle_
 
848 - 14.10.19 - 00:31
(845) Кстати в этом и заключается опасность использования термина "функция" вместо нашего "свойство". Все же функция воспринимается большинством, как какаято последовательность действий, в результате которых, возвращается какое-то значение. Нам бы тогда следовало использовать термин "чистая функция" или что-то подобное.
   _DAle_
 
849 - 14.10.19 - 00:35
(847) Да можно проще. Позаимствовать синтаксис, например, из с++ namespace::name или что-то подобное, но опять же - это нарушение обратной совместимости. Да и просто иметь два разных синтаксиса обращения к свойствам.. ну, как по мне - это довольно кривое решение. Мне лично оно не нравится, я буду против, хотя это вряд ли что-то изменит.
   Ещё1
 
850 - 14.10.19 - 00:54
(849) Ну да, тут плюсы и минусы. Два варианта синтаксиса в 1 языке - однозначно минус. А если их начнут ещё смешивать в одном модуле...
С другой стороны, ООП привычно очень многим, и записывая "MyClass." можно тут же получить список свойств класса.
Вобщем, совсем неоднозначно.
   _DAle_
 
851 - 14.10.19 - 00:57
(850) Тут еще беда в том, что их точно начнут смешивать и не просто в одном модуле, а в одной строке. Ведь foo(a + 5) все равно будут писать в нынешнем синтаксисе.
   Bro
 
852 - 14.10.19 - 08:37
(800) OK, убить двух человек: kill(Person a, Person b) объект НАД КОТОРЫМ выполняется действие это a или b?
(805) Свойство модуля тогда уж. Также как и грубо говоря в 1С процедура это процедура модуля менеджера объекта.
(828) "Не в нашей, а в вашей". А вообще Asmody, мы на этом деньги зарабатываем. Вы знаете сколько блог на хабре стоит для 20 сотрудников например? Или перевод нэйтивами?
(838) Потому что функция подразумевает вычисление. Также как и остальные языки использовали другой термин (Метод, Поле) -> Свойство (метод и поле объединили в свойство)
(842) Ну нет, в духе ООП назначили бы главную жену, скажем Organization и было бы Organization.quantity(Stock, Sku).
   НиколаевГ
 
853 - 14.10.19 - 08:48
(852) Вот только более-менее проясняется - опять ты всё путаешь. Что, quantity(Sku sku) = GROUP SUM quantity(Organization o, Stock s, sku) разве не подразумевает вычисление?
   Bro
 
854 - 14.10.19 - 08:52
(853) Свойство в других языках тоже подразумевает ИЛИ вычисление ИЛИ чтение поля. Здесь тоже. То что вы написали - вычисление. Но если бы quantity = DATA LONG (Sku) то было бы чтение. Но важно, что тот кто использует quantity этого не знает. Он обращается к свойству.
   Bro
 
855 - 14.10.19 - 08:55
(852) *тьфу - любимую жену, совсем начал классику забывать :(
   Asmody
 
856 - 14.10.19 - 09:02
(852) На мисте дешевле? Ну вот и пользуйтесь
   Bro
 
857 - 14.10.19 - 09:06
(856) у мисты другая функция. Это максимально токсичное сообщество, которое дает почувствовать каждую царапину которая есть на теле. Идеальный метод диагностики.
   Провинциальный 1сник
 
858 - 14.10.19 - 09:10
А кстати, в фузионе есть такой замечательный числовой тип данных, как в 1с - числа практически неограниченной длины и точности с нефиксированной разрядностью?
   ДенисЧ
 
859 - 14.10.19 - 09:11
(858) "числа практически неограниченной длины "
Это в какой 1с числа неограниченной длины?
   Михаил Иванович
 
860 - 14.10.19 - 09:14
(859) 9.2.385
 
 Рекламное место пустует
   Провинциальный 1сник
 
861 - 14.10.19 - 09:15
(859) Я про числовые переменные, не про хранение в базе
   НиколаевГ
 
862 - 14.10.19 - 09:16
(854) Ваши объяснения, что такое свойство:
     Свойство - это функция
     Но это не функция
     Но иногда функция
Спасибо за доходчивые объяснения :))
   Bro
 
863 - 14.10.19 - 09:16
(858) Можно в принципе добавить NUMERIC (по аналогии со STRING как мы безразмерный добавили), это в общем то пару строк, но там проблемы с СУБД отличными от PostgreSQL будут:

NUMERIC
without any precision or scale creates a column in which numeric values of any precision and scale can be stored, up to the implementation limit on precision. A column of this kind will not coerce input values to any particular scale, whereas numeric columns with a declared scale will coerce input values to that scale. (The SQL standard requires a default scale of 0, i.e., coercion to integer precision. We find this a bit useless. If you're concerned about portability, always specify the precision and scale explicitly.)

Но помечу сейчас, если что сделаем просто очень большой NUMERIC
   Bro
 
864 - 14.10.19 - 09:18
(862) В статье все объяснено достаточно формально. Потом я уточнил, что это чистая функция с возможностью записи значений. Но тут все равно чудес не будет понятие новое, поэтому проще по примерам понимать. Вон Еще1 понял сам без дополнительных объяснений (не помню чтобы у него вопросы по этому поводу были). Да и мы когда обучаем людей с этим не сталкиваемся.
   Bro
 
865 - 14.10.19 - 09:24
(850) Вот тут сложно сказать. Я когда писал статью, писал что смешанный синтаксис:
f(A a, B b, C c) = GROUP SUM g(X x) IF h(x) = c BY a(x), b(x)
это треш и не надо его использовать. А потом подсел и сам начал его использовать :) Так что может со "смешанным" синтаксисом все не так страшно будет :)
   НиколаевГ
 
866 - 14.10.19 - 09:25
(864) Ну, ваш коллега объясняет лучше, причем намного. А вы даже не пытаетесь посмотреть с точки зрения того, кому объясняете, упуская очевидные вам, но не очевидные другим, нюансы. В результате складывается впечатление какой-то малопонятной мешанины.
   Провинциальный 1сник
 
867 - 14.10.19 - 09:26
(863) Вопрос не о размере хранения данных в базе, а об отсутствии потери точности при расчетах. То есть, чтобы точность результата всегда (в разумных пределах, конечно) была больше или равна точности операндов. Плавающие типы данных не подходят именно по этой причине, в них теряется точность априори, а для учетных систем это недопустимо.
   ProgerVShapke
 
868 - 14.10.19 - 09:29
А что насчёт микросервисов? Их возможно делать?
   Ещё1
 
869 - 14.10.19 - 09:31
(852) > убить двух человек: kill(Person a, Person b) объект НАД КОТОРЫМ выполняется действие это a или b?
Давайте различать действия (kill, обычно задаются глаголами) и свойства объектов/классов, о которых была речь выше. Свойства не производят действия над объектами.
   Ещё1
 
870 - 14.10.19 - 09:36
(852) > Свойство модуля тогда уж. Также как и грубо говоря в 1С процедура это процедура модуля менеджера объекта.
Модуль - это просто кусок текста на lsFusion. Он не может обладать свойствами типа Количество, Выбранный из бизнес-области.
Процедура менеджера объекта в 1С - это метод этого объекта, не свойство.
   Asmody
 
871 - 14.10.19 - 09:40
У меня тут такое приключилось.
Я набил какие-то данные, потом поменял структуру класса и у меня пропали все введенные ранее значения!
На месте ссылок стоит "Не определено".
Это, простите, как?
   Bro
 
872 - 14.10.19 - 09:41
(867) Там проблема не столько в потери точности, а в том что double точку хранит в двоичной системе исчисления, а финансы и ввод данных пользователей в десятичной (так то в научных задачах double отлично подходит). Я понял вашу мысль, PostgreSQL поддерживает такой тип (Java работает с BigDecimal для всех Numeric так что ей фиолетово по определению), так что может сегодня и добавим его. Конечно что с MS SQL и Oracle непонятно что делать, но по изучаем еще вопрос.
(868) Вот тут я отвечал про это:
https://habr.com/ru/company/lsfusion/blog/465573/#comment_20592399
(869) Ну ок, возьмите sum, equals, better. Ну или тот же остаток, это свойство товара или склада.
(870) Я может что-то путаю, но мне казалось что отличие модуля объекта и модуля менеджера в том что в модуле объекта есть this, а в модуле менеджера this нет (то есть все процедуры static по сути).
(871) Что значит поменяли структуру класса? Переименовали?
   Asmody
 
873 - 14.10.19 - 09:42
(872) Перенес описание в другой модуль
   Ещё1
 
874 - 14.10.19 - 09:43
(852) > Потому что функция подразумевает вычисление. Также как и остальные языки использовали другой термин (Метод, Поле) -> Свойство (метод и поле объединили в свойство)
В ООП поле - это атрибут класса/объекта (в 1С это реквизиты классов/объектов).
Метод - это действие над объектом, инкапсулированное в него.
Свойство класса/объекта - это способ обращения к атрибутам класса для чтения и изменения. Т.е. через свойства можно менять атрибуты класса извне. Писал здесь (792).
   Bro
 
875 - 14.10.19 - 09:46
(873) Тем самым вы namespace сменили (то есть имя свойства). Надо было или тот же namespace модулю делать, или миграцию добавлять (откуда платформе узнать, что вы не просто удалили один класс и добавили другой). Хотя да, я сейчас понял что при переименовании Rename(SHIFT+F6) мы автоматическую генерацию скрипта миграции поддержали, а при Move (F6) - пока нет. Сейчас помечу, сделаем.
   Bro
 
876 - 14.10.19 - 09:49
(874) Метод не обязательно действие, это может быть и вычисление (то есть оно может не изменять состояние объекта). Хотя свойство в классических языках да подразумевает "чистоту", то есть только вычисление. Хотя непонятно как это все противоречит тому что я написал.
   Asmody
 
877 - 14.10.19 - 09:52
(875) Так оно бы, может быть, где-то бы ругнулось?
   Asmody
 
878 - 14.10.19 - 09:56
А то получается я легким рефакторингом похерил базу
   Asmody
 
879 - 14.10.19 - 09:57
И как теперь вернуть нажитое непосильным трудом взад, не меняя модулей?
   Ещё1
 
880 - 14.10.19 - 09:57
(852) > Ну нет, в духе ООП назначили бы главную жену, скажем Organization и было бы 1) Organization.quantity(Stock, Sku).
И это имело бы смысл. Так же как и 2) Stock.quantity(Organization, Sku) и 3) Sku.quantity(Organization, Stock).
А с точки зрения бизнеса формулировки звучали бы немного по разному.
1) quantity - свойство организации, задающее количество у неё некоего товара на некоем складе.
2) quantity - свойство склада, указывающее сколько некоего товара некоей организации на нём хранится.
3) quantity - свойство товара, задающее его количество для некоей организации и склада.
Хотя с точки зрения программы - это всё эквивалентно.
   Bro
 
881 - 14.10.19 - 10:00
(877) В продакшне на такие вещи стоит защита. В разработке предполагается, что разработчик знает что делает.
(879) Там колонки не удаляются а переименовываются в _deleted_ можете вернуть назад код, зайти и переименовать колонки назад. Есть еще вариант из копии восстановить колонки (в администрировании есть). Но вообще это проблема серии ой я сделал DELETE FROM a; Как мне вернуть все назад.
   Asmody
 
882 - 14.10.19 - 10:02
(881) DELETE FROM - это _сознательный_ способ выстрелить себе в ногу.
А потеря данных из-за переноса куска кода из одного файла в другой - это, извините, пиздец.
   Bro
 
883 - 14.10.19 - 10:05
(880) Знаете у меня даже в java часто такая дилемма возникает. Куда положить метод и иногда бесит, что нужно выбирать, и для этого чуть ли не монетку бросать. Как раз бизнесу фиолетово кто там главный, ему важнее сам показатель.
(882) А вы его F6 или copy paste переносили?
   Ещё1
 
884 - 14.10.19 - 10:06
(865) Возможно и не страшно. В других же языках как-то сочетают функциональныйи ООП стиль. Важно только так продумать синтаксис языка, чтобы не было неоднозначности при смешении стилей.
   НиколаевГ
 
885 - 14.10.19 - 10:07
(881) Вы реально страшные люди... Работа без права на ошибку, блин.
   Bro
 
886 - 14.10.19 - 10:08
(885) DELETE в SQL обладает еще более страшными последствиями. WHERE неправильно указал и пиздец. Но как то мир не остановился.
   CrushBy
 
887 - 14.10.19 - 10:11
(885) With great power comes great responsibility.
   _DAle_
 
888 - 14.10.19 - 10:12
(873) Дело в том, что при переносе в другой модуль у вас изменилось каноническое имя свойства, по которому оно идентифицируется. (Если бы вы прописали то же пространство имен, этого бы не произошло). В это каноническое имя входят: имя пространства имен, имя свойства, и сигнатура свойства, то есть список классов параметров. Подробнее: https://documentation.lsfusion.org/pages/viewpage.action?pageId=35521066#id-Именование-canonicalname
При переименовании DATA свойства, либо переносе его в другое пространство имен, необходимо описать это изменение в скрипте миграции. https://documentation.lsfusion.org/pages/viewpage.action?pageId=8945688
   Ещё1
 
889 - 14.10.19 - 10:16
(870) Я может что-то путаю, но мне казалось что отличие модуля объекта и модуля менеджера в том что в модуле объекта есть this, а в модуле менеджера this нет (то есть все процедуры static по сути).
На самом деле неважно, в этой дискуссии важно, что эти процедуры не являются свойствами. Они могут быть методами соответствующих классов, или просто неклассовыми процедурами, но не свойствами этих классов.
   НиколаевГ
 
890 - 14.10.19 - 10:18
(886) (887) А предупреждение выдать на уровне платформы - слабо?
   Ещё1
 
891 - 14.10.19 - 10:20
(876) Вы ранее написали "метод и поле объединили в свойство". Это не совсем точная формулировка.
   Ещё1
 
892 - 14.10.19 - 10:24
(878) Это недоделка конкретно этого рефакторинга. Изменения в коде программы не отражались в структуре БД. Я с этим тоже сталкивался уже, надеюсь допилят.
   Bro
 
893 - 14.10.19 - 10:26
(892) Изменение в коде всегда отражаются в структуре БД. Вопрос соответствия кода до и кода после (то есть между запусками).
   Ещё1
 
894 - 14.10.19 - 10:30
(883) В бизнесе как раз важно.
Смотрите, задача: принеси мне отчёт по наличию товара "Хлеб Бородинский" на наших складах.
Решение: вот вам 20 отчётов по всем нашим складам, в каждом из которых указано наличие "Хлеба Бородинского".
С точки зрения бизнеса это разные вещи? Разные. А с точки зрения программы разницы нет, те же показатели только чуть по-другому сгруппированы.
   НиколаевГ
 
895 - 14.10.19 - 10:46
(891) Угу. В Фузине свойство - это глобальная функция, метод и поле одновременно. При этом свойство ничем  из этого не является.
   Flyd-s
 
896 - 14.10.19 - 10:48
Теперь я понял почему они так носятся с переименованием классов в IDE, чуть не правильно код написал и база убилась
   Bro
 
897 - 14.10.19 - 10:48
(895) Ну методы в фузине - это действия. То есть действия отвечают за изменения, свойства за чтения и вычисления.
   orefkov
 
898 - 14.10.19 - 10:49
(822)
О каком множественном полиморфизме вы говорите в этом случае? У вас в рантайме по реальным типам параметров подбирается функция? Или таки при компиляции? Тогда это обычная перегрузка методов, которая много где есть, никакой революции.
   Bro
 
899 - 14.10.19 - 10:52
(898) в рантайме по реальным типам:
https://habr.com/ru/company/lsfusion/blog/458376/#poly
Там правда для действий пример, но для свойств все аналогично
   Bro
 
900 - 14.10.19 - 10:53
(899) Но и перегрузка функций тоже есть в lsFusion если вы об этом. Никаких СделатьЧтоТоДляСкладаТовараОрганизации не надо.
  1  2  3  4  5  6  7  8  9  10  11   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.