C# vs Kotlin

Привет всем!

Java c C# уже сравнивали несколько раз. А как насчёт улучшенного (а может кто то считает "улучшенного") варианта java - языка Kotlin?

0

Сообщение от Usaga расстояние между точками - вычисляемая вещь и не требует своей отдельной сущности

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

Добавлено через 3 минуты

Сообщение от Usaga Никаких завязок на глобальные объекты не должно быть и в помине.

С каких делов? К примеру глобальная коннекция к БД или к сокету? Ее тоже при закрытии одной формы для всех уничтожать будете? Или весь набор справочников тоже на каждую форму тащить будете?
Может с таких что вам эти worst practicles внушили чтобы впарить GC-гуано?

0

Сообщение от Fulcrum_013 НА самом деле это ограничение которое надо соблюдать. Т.е. оно не вычисляется а положение точек меняется так чтобы это расстояние было заданным. Т.е. это сущность данных точно так же редактируемая и т.д., а для вычисляемых размеров существует сущность которая хранит настройки отображения и т.д. или опять же ограничения на минимально/максимально допустимые и т.д. Ну и опять же для любого элемента чертеж существует элемент UI который тоже как не крути сущность которую тоже нужно при этом удалять. Не пытайтесь увиливать от признания того факта что GC просто абсолютно непригоден для подобных задач. А то в результате ваших потуг как то переиначивать задачу, вообще своей безграмоностью блеснете по самые немогу.

В каком месте это "ограничение"? Расстояние между двумя точками - функция от этих двух точек. Если вам нужны дополнительные свойства (цвет линии, другие визуальные отличия), то можно расстояние сделать и сущностью. Зависимой от обеих точек. С удалением точек, удалится и сущность "расстояние". В чём противоречие и увиливание? Кстати, вы же в курсе про Value Types?

Сообщение от Fulcrum_013 С каких делов? К примеру глобальная коннекция к БД или к сокету? Ее тоже при закрытии одной формы для всех уничтожать будете? Может с таких что вам эти worst practicles внушили чтобы впарить GC-гуано?

Какая ещё "глобальная коннекция"?))))) Понадобились данные? Подключились к СУБД, взяли что надо, закрыли подключение. Всё. ADO.NET подключения хранит в пуле, так что всё крайне эффективно. Или ваш дофига профессионализм (явно колхозный) говорит о том, что подключение надо удерживать вечно?)))

Когда создаётся форма, то формируется и ViewModel для неё. Данные для неё берутся откуда надо: напрямую из СУБД или из кешей. Но не по ссылке, а копируются. Когда форма закрывается, то и ViewModel становится не нужна. GC убирает обоих. Никаких проблем. Никаких ручных занулений ссылок.

0

Сообщение от Usaga В каком месте это "ограничение"?

Вы вообще слышали когда нить такой термин как "набор ограничений положения элементов"?

Сообщение от Usaga С удалением точек, удалится и сущность "расстояние"

А если надо удалить одну точку а вторую оставить? Сущность "расстояние" при этом тоже должно удалится потому что не может одним концом висеть в воздухе.

Добавлено через 3 минуты

Сообщение от Usaga Какая ещё "глобальная коннекция"?)))))

Для получения живых обновлений данных к примеру.

Добавлено через 1 минуту

Сообщение от Usaga Когда форма закрывается, то и ViewModel становится не нужна

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

Добавлено через 10 минут

Сообщение от Usaga Расстояние между двумя точками - функция от этих двух точек

Положение точек это точно так же система уравнений заданных ограничений (расстояний и т.д.).

Добавлено через 1 минуту

Сообщение от Usaga Кстати, вы же в курсе про Value Types?

Они причем до взаимосвязей между сущностями?

0

Сообщение от Fulcrum_013 Вы вообще слышали когда нить такой термин как "набор ограничений положения элементов"?

Ограничений чего? На уровне бизнес-логики или GC?

Сообщение от Fulcrum_013 А если надо удалить одну точку а вторую оставить? Сущность "расстояние" при этом тоже должно удалится потому что не может одним концом висеть в воздухе.

Просто забыли ссылку на эту сущность и всё.

Сообщение от Fulcrum_013 Для получения живых обновлений данных к примеру.

Как это противоречит идее ViewModel?

Сообщение от Fulcrum_013 Справочники которые к куче форм лепятся тоже каждый раз перекачивать и т.д. в полном объеме вместо того чтобы между формами расшарить?

Ссылки на справочники легко шарятся через ViewModel. Но ссылки на эти справочник не протекают через ViewModel. Так что всё чётко.

Сообщение от Fulcrum_013 Положение точек это точно так же система уравнений заданных ограничений (расстояний и т.д.).

Система уравнений над заданными переменными, так ведь?

Сообщение от Fulcrum_013 Они причем до взаимосвязей между сущностями?

Расстояние можно задать не отдельной сущностью, а значимыми типом. Тогда GC вообще будет не при делах.

0

Сообщение от Usaga Расстояние можно задать не отдельной сущностью, а значимыми типом.

Не получится. Потому что оно ссылается на элементы. Ну и при этом там много других дел кроме самого числа хранится.

Сообщение от Usaga Тогда GC вообще будет не при делах.

Та то что он вообще нигде не при делах это и ежу понятно. Вопрос в том что иерархию по любому как то разбирать придется. Иначе где то потечет. Те же value types сырые тоже в массивы динамические запихивать надо, и если не удалять ненужные это утечка которую GC вообще не обнаружит. Совсем забыл что GC ваш с элементами массивов и т.д. вообще не умеет абсолютно ничего, и сами массивы объекты классов хранить тоже не умеют.
Т.е. вы просто пытаетесь сказать что GC для этого не предназначен?
Так я вам именно это и пытаюсь доказать - он вообще не предназначен для обработки иерархий взаимосвязей, которые возникают в подавляющем большинстве задач, а то для чего он годен актуально не более чем в 0,0001% случаев.

0

Сообщение от Fulcrum_013 Не получится. Потому что оно ссылается на элементы. Ну и при этом там много других дел кроме самого числа хранится.

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

Сообщение от Fulcrum_013 Та то что он вообще нигде не при делах это и ежу понятно. Вопрос в том что иерархию по любому как то разбирать придется. Иначе где то потечет. Те же value types сырые тоже в массивы динамические запихивать надо, и если не удалять ненужные это утечка которую GC вообще не обнаружит. Совсем забыл что GC ваш с элементами массивов и т.д. вообще не умеет абсолютно ничего, и сами массивы объекты классов хранить тоже не умеют. Т.е. вы просто пытаетесь сказать что GC для этого не предназначен? Так я вам именно это и пытаюсь доказать - он вообще не предназначен для обработки иерархий взаимосвязей, которые возникают в подавляющем большинстве задач, а то для чего он годен актуально не более чем в 0,0001% случаев.

Вы вообще понимаете, что означает эта фраза "value types"?)) Судя по всему, не очень)

0

Сообщение от Usaga Но ссылки на эти справочник не протекают через ViewModel.

Выбор значения из справочника типа на эти справочники вообще никак не завязан?

Добавлено через 4 минуты

Сообщение от Usaga С чего тут обязательна стала ссылка на сущности?

Ну к примеру с того что он должен как то идентефицировать те элементы между которыми указывает(или считает) размер. ну типа x1 и x2

Сообщение от Usaga Местный суррогатный ключ не можно применить, если надо?

Да как ссылку не назови она ссылкой и останется, не зависимо от адресного пространства в котором она является адресом.
Так что в какой форме ссылки не задавай а разбирать инфраструктуру связей так или иначе придется.
Очевидно что GC в этом не помощник.

Добавлено через 1 минуту

Сообщение от Usaga Система уравнений над заданными переменными, так ведь?

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

Добавлено через 5 минут

Сообщение от Usaga Судя по всему, не очень)

Судя по всему вы нихрена просто не понимаете о чем говорите. Какие к глиняной маме Value Types если список параметров каждой сущности включая размеры и т.д. на скрин размером по высоте? Классы онли. Причем полиморфные классы, ибо типов ограничений там как собак нерезаных и все в одной системе участвуют и в одном чертеже присутсвуют.

Добавлено через 10 минут

Сообщение от Usaga Вы вообще понимаете, что означает эта фраза "value types"?))

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

Добавлено через 15 минут

Сообщение от Usaga Как это противоречит идее ViewModel?

Зачем держать кучу коннекций когда достаточно одной? Тоже самое касается справочников которые точно так же обновлябельны через оную единую коннекцию и расшариваемы между формами/зависимыми модулями данных. При этом (неожиданно) может существовать ограничение на количество одновременно активных коннекций к удаленному источнику.

0

Сообщение от Fulcrum_013 Выбор значения из справочника типа на эти справочники вообще никак не завязан?

Не обязательно. Можно снимать копию со справочника, можно заворачивать все данные формы (в том числе и справочники) во ViewModel, которую потом просто выбросить. Не забывайте, что завязывается форма на справочник, а не справочник на форму.

Сообщение от Fulcrum_013 Ну к примеру с того что он должен как то идентефицировать те элементы между которыми указывает(или считает) размер. ну типа x1 и x2

Для этого не обязательно быть сущностью самостоятельной. Достаточно или ссылки держать на связываемые объекты или суррогатные ключи какие-то.

Сообщение от Fulcrum_013 Да как ссылку не назови она ссылкой и останется, не зависимо от адресного пространства в котором она является адресом. Так что в какой форме ссылки не задавай а разбирать инфраструктуру связей так или иначе придется. Очевидно что GC в этом не помощник.

Суррогатный ключ - идентификатор - является, по сути, слабой ссылкой и никак не помешает GC убрать объект, если на того не останется ссылок. Это кем надо быть, что бы идентификатор от ссылки не отличить?

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

И в чём проблема?

Сообщение от Fulcrum_013 Судя по всему вы нихрена просто не понимаете о чем говорите. Какие к глиняной маме Value Types если список параметров каждой сущности включая размеры и т.д. на скрин размером по высоте? Классы онли. Причем полиморфные классы, ибо типов ограничений там как собак нерезаных и все в одной системе участвуют и в одном чертеже присутсвуют.

Не, я не треплюсь бездоказательно, так что мне таких обвинений не надо, пожалуйста. Value Types прекрасно могут подойти к данной ситуации вне зависимости от количества полей.

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

И в чём противоречие-то?

Сообщение от Fulcrum_013 Зачем держать кучу коннекций когда достаточно одной? Тоже самое касается справочников которые точно так же обновлябельны через оную единую коннекцию и расшариваемы между формами/зависимыми модулями данных. При этом (неожиданно) может существовать ограничение на количество одновременно активных коннекций к удаленному источнику.

Ну так в этом и прикол ViewModel. Собрать все необходимые форме данные в один объект-источник, который потом выкинуть, как станет не нужны. И который сможет развязать зависимости между моделями \ справочниками и кодом формы.

0

Сообщение от Usaga И который сможет развязать зависимости между моделями \ справочниками и кодом формы.

Вот я вас и прошу объяснить как GC будет разрывать зависимости с источниками данных которые должны выжить после закрытия формы (справочниками коннекциями и т.п. внутренностями постоянно живущих модулей данных). Очевидно что GC в этом вопросе не помощник.

Добавлено через 5 минут

Сообщение от Usaga если на того не останется ссылок

А в том то и прикол что убрать нужно объект на который есть ссылки.

Добавлено через 3 минуты

Сообщение от Usaga alue Types прекрасно могут подойти к данной ситуации вне зависимости от количества полей.

пример
Какие к глиняной маме value types для его замены?

Добавлено через 2 минуты

Сообщение от Usaga И в чём проблема?

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

Добавлено через 5 минут

Сообщение от Usaga Это кем надо быть, что бы идентификатор от ссылки не отличить?

Наверное надо быть Usaga чтобы не понимать что суть ссылки не изменена для любого адресного пространства, и к примеру не понимать того что ключ это точно такая же ссылка в адресном пространстве идентификаторов. А соответственно пытаться лепить какую то фигню вместо O(1) доступа там где переход Log(n) доступу по ключу ничего принципиально не меняет.

Добавлено через 2 минуты

Сообщение от Usaga Можно снимать копию со справочника,

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

Добавлено через 16 минут

Сообщение от Usaga Достаточно или ссылки держать на связываемые объекты

Дак я вам о чем и говорю - он ссылается на связываемые объекты. Связываемые объекты при этом ссылаются на него. Точно так же на связываемые объекты и на сам размер ссылается чертеж. Нужно удалить размер при удалении одного из элементов на которые он ссылается.

0

Сообщение от Fulcrum_013 Вот я вас и прошу объяснить как GC будет разрывать зависимости с источниками данных которые должны выжить после закрытия формы (справочниками коннекциями и т.п. внутренностями постоянно живущих модулей данных). Очевидно что GC в этом вопросе не помощник.

Никак. Связи от формы к источникам не будут учитываться. Т.е. ссылки из формы на разного рода коллекции\объекты. Достаточно отписаться от событий со стороны VM. А это, как правило, одно единственное событие (если брать для примера практики принятые в .NET). Так что проблемы тут и нет.

Сообщение от Fulcrum_013 А в том то и прикол что убрать нужно объект на который есть ссылки.

Это вызывает какие-то сложности?

Сообщение от Fulcrum_013 Какие к глиняной маме value types для его замены?

Если исключить полиморфное поведение и оставить только данные, то можно классы заменить структурами. Структуры в куче не отсвечивают, что сильно снижает memory pressure. Это не всегда возможно, конечно же, но механизм такой есть. Нужно пользоваться. В случае с объектом ограничением, какие проблемы вы видите, что он ссылается на объекты геометрии для выполнения своих рассчётов?

Сообщение от Fulcrum_013 Еще раз - удалить размер нужно при удалении одного из элементов с которыми он связан двунаправленными ссылками. т.е. оба элемента ссылаются на него точно так же как он на них.

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

Сообщение от Fulcrum_013 Наверное надо быть Usaga чтобы не понимать что суть ссылки не изменена для любого адресного пространства, и к примеру не понимать того что ключ это точно такая же ссылка в адресном пространстве идентификаторов. А соответственно пытаться лепить какую то фигню вместо O(1) доступа там где переход Log(n) доступу по ключу ничего принципиально не меняет.

Это один из возможных вариантов ухода от прямых ссылок (который вряд ли вообще нужен). Смею заметить, что ссылка остаётся ссылкой в лбом языке. Так что в С++ их точно так же нужно будет разрывать, чтобы выкинуть объект. Только делать это нужно будет ручками.

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

Ничего синхронизировать не надо. Справочники в 99% случаев только читаются. Копию справочника можно будет смело выкинуть вместе с формой. Но это всё будет нужно только, если будет связь от справочника к форме (т.е. справочник на форму будет держать ссылку), чего практически никогда не бывает. И какая связь с дельфи и быдлоформошлёпством?

Сообщение от Fulcrum_013 Дак я вам о чем и говорю - он ссылается на связываемые объекты. Связываемые объекты при этом ссылаются на него. Точно так же на связываемые объекты и на сам размер ссылается чертеж. Нужно удалить размер при удалении одного из элементов на которые он ссылается.

Проходим по всем участникам и режем ссылки.

Я правильно понял, что вы начали придумывать новый пример бесполезности GC?

0

Сообщение от Usaga Проходим по всем участникам и режем ссылки.

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

Сообщение от Usaga Я правильно понял, что вы начали придумывать новый пример бесполезности GC?

Это все тот же пример который вы не в состоянии осилить.

Добавлено через 1 минуту

Сообщение от Usaga Но это всё будет нужно только, если будет связь от справочника к форме (т.е. справочник на форму будет держать ссылку), чего практически никогда не бывает.

На самом деле она двунаправленная и всегда.

Добавлено через 50 секунд

Сообщение от Usaga Ничего синхронизировать не надо.

Справочник обновился с другой машины. Без обновления копии целостность данных нарушена.

Добавлено через 8 минут

Сообщение от Usaga Только делать это нужно будет ручками.

Ну это в языках с GC ручками. А в С++ можно и автоматически. Если точнее - то при помощи кастомных библиотечных средств которые запускаются автоматически при разрыве ссылки.

Добавлено через 5 часов 8 минут

Сообщение от Usaga Это один из возможных вариантов ухода от прямых ссылок (который вряд ли вообще нужен). Смею заметить, что ссылка остаётся ссылкой в лбом языке.

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

0

Сообщение от Fulcrum_013 Именно потому что без прохода по участникам GC бесполезен.

Бесполезность не доказана. С нас только разорвать ссылки, чтобы показать, что объект стал не нужен. Дальше вступает в дело GC. Более того: данный пример крайне редкий. В основном, ссылки никто не трогает. Так что этот "минус" явно натянут.

Сообщение от Fulcrum_013 Это все тот же пример который вы не в состоянии осилить.

Ещё как в состоянии. Только бесполезности GC он не демонстрирует. Вообще никак.

Сообщение от Fulcrum_013 На самом деле она двунаправленная и всегда.

Нет. Контрол на форме получает ссылку на "источник данных" для отображения данных из этого источника. Сам "источник" ссылок на контрол не держит. Значит ничто не помешает эту форму убрать. Ссылка на форму сформируется только, если форма подпишется на какое-то событие. Так что не двунаправленные и не всегда.

Сообщение от Fulcrum_013 Справочник обновился с другой машины. Без обновления копии целостность данных нарушена.

Копия снимается с оригинала при открытии формы. Как правило, справочники не нужно поддерживать в актуальном состоянии в каждый момент времени. Только на время существования формы. А там, где нужно, можно по таймеру\событию обновлять. Это не есть проблема и уж тем более ни какая-то неразрешимая и как-то влияющая на GC (или наоборот).

Сообщение от Fulcrum_013 Ну это в языках с GC ручками. А в С++ можно и автоматически. Если точнее - то при помощи кастомных библиотечных средств которые запускаются автоматически при разрыве ссылки.

Т.е. написание кастомных библиотек - это круто, а GC, который сам всё может - фуфло? Приведённый вами тут пример крайне редко встречается. А там, где встречается, то какие могут быть проблемы обнулить пару ссылок? Вы любые возможности изыскиваете, что придумать и подтянуть за уши недостатки GC?

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

Я этот момент не оспариваю. Но природа таких ссылок иная. И вполне применимая, как вариант слабой ссылки. Есть ключи с обеих сторон, но для GC они не являются препятствием. Так что, противоречий тут особо и нет.

0

Сообщение от Usaga Бесполезность не доказана. С нас только разорвать ссылки, чтобы показать, что объект стал не нужен. Дальше вступает в дело GC. Более того: данный пример крайне редкий. В основном, ссылки никто не трогает. Так что этот "минус" явно натянут.

Как это не доказана если GC не способен решить задачу уборки без ручного прохода по участникам?

Добавлено через 4 минуты

Сообщение от Usaga который сам всё может - фуфло

Дык ниче оный GC не может как видим. А библиотеки реально могут все. Потому что GC рассчитан на одну задачу, актуальность которой в районе нуля. А вот библиотеки позволяют кастомизировать автоматику под любую задачу. К примеру задача подобных обходов которые с GC делается только вручную пишется один раз потом используется с любым набором взаимосвязей. И так под любой класс задач, при этом есть возможность совмещения разных автоматов для разных объектов в одной программе. А GC работу всех этих автоматов заставляет делать вручную.

Добавлено через 52 секунды

Сообщение от Usaga Приведённый вами тут пример крайне редко встречается

На каждом шагу он встречается. Смесь композита и обсервера и лайтвеигхт за компанию - основа современной разработки особенно в плане GUI. А вот задачи с которыми способен справится GC действительно редкость.

Добавлено через 2 минуты

Сообщение от Usaga Только на время существования формы.

За время существования формы они могут сто раз обновится в т.ч и с другой машины. При этом на каждой долбанной форме на каждое долбанное лукап-поле стоит кнопка добавить которая очень часто открывает другую форму для редактирования справочника. БУдем кучу бесполезных копий плодить или все таки будем делать все как положено по лайтвеигхту?

Добавлено через 17 минут

Сообщение от Usaga Есть ключи с обеих сторон, но для GC они не являются препятствием.

Только опять же ключи не вычистятся из объектов без обхода. При этом невозможно подвесить бинд на ключах с обеих сторон - GC его тут же уберет. А если оставить на него какую либо ссылку опять же потребуется ручной проход для его удаления. Так что ключи в данном случае не более чем тормозистор доступа а не решение задачи уборки.

0

Сообщение от Fulcrum_013 Как это не доказана если GC не способен решить задачу уборки без ручного прохода по участникам?

Только в оговоренном тут случае. Да и то потому, что не имеет права в такой ситуации что-то выкидывать. Но и решение не сложное.

Сообщение от Fulcrum_013 Дык ниче оный GC не может как видим.

Один редкий случай - теперь "всё"? С каких пор? Не сильное ли это преувеличение?

Сообщение от Fulcrum_013 Потому что GC рассчитан на одну задачу, актуальность которой в районе нуля.

Это в вашем вымышленном мире так.

Сообщение от Fulcrum_013 На каждом шагу он встречается. Смесь композита и обсервера и лайтвеигхт за компанию - основа современной разработки особенно в плане GUI. А вот задачи с которыми способен справится GC действительно редкость.

Сколько работаю с WinForms, ещё ни разу не приходилось вручную ссылки разрывать. И система-то у нас из сотен форм. Что я делаю не так?

Сообщение от Fulcrum_013 За время существования формы они могут сто раз обновится в т.ч и с другой машины. При этом на каждой долбанной форме на каждое долбанное лукап-поле стоит кнопка добавить которая очень часто открывает другую форму для редактирования справочника. БУдем кучу бесполезных копий плодить или все таки будем делать все как положено по лайтвеигхту?

Справочники редактируются из одного места - админки. В остальных случаях, они read only и могу быть не сильно актуальными в течении сессии работы с формой. Это уже от требований к функционалу зависит. Тут с GC вообще никакой связи. То, что форма ссылку держит на справочник не "подвесит" эту форму, ибо справочник не обязан держать ссылку на форму. Это может быть только во ViewModel, но там ссылка на форму может быть одна единственная, которую задиспозить не проблема.

0

Сообщение от Usaga С нас только разорвать ссылки, чтобы показать, что объект стал не нужен

Как у вас все запущено. Полный ручник. А нам вообще ниче не делать можно - только типы ссылок указать при объявлении. Остальное делает автоматика. Даже с искоробочной заплаткой для бедных. А средства для богатых еще и позволяют пнуть объект который нужно убить раньше чем он выйдет из скопа. Причем пнуть он может себя и сам из своего метода. А все остальное опять же делает автоматика.

Добавлено через 1 минуту

Сообщение от Usaga Справочники редактируются из одного места - админки

ВВы адресную книгу к примеру клиенту предлагаете только из админки редактировать или список его телефонов?

0

Fulcrum_013, нигде никакого ручника нет. Ещё раз для повторюсь, что такая практика дико редка, если вообще применяется.

Сообщение от Fulcrum_013 А нам вообще ниче не делать можно - только типы ссылок указать при объявлении.

Я дико рад за "вас". Только бесполезность GC мы так и не увидели.

0

Сообщение от Usaga ибо справочник не обязан держать ссылку на форму

Обязан. Для того чтобы отдавать апдейты.

Добавлено через 1 минуту

Сообщение от Usaga Только бесполезность GC мы так и не увидели.

НУ вы же сами сказали - только вручную. Т.е. GC бесполезен в плане уборки мусора.

0

Сообщение от Fulcrum_013 ВВы адресную книгу к примеру клиенту предлагаете только из админки редактировать или список его телефонов?

Какая разница? Если требования позволяют не отслеживать изменения этого справочника, пока открыта форма, где этот справочник отображается и используется? Сиюсекундные обновления крайне редко где нужны. И даже если их реализовывать то как этому мешает GC?

Добавлено через 1 минуту

Сообщение от Fulcrum_013 Обязан. Для того чтобы отдавать апдейты.

Не обязан. Связь должна быть с ViewModel, которая одна и которая все ивенты от модели и справочников агрегирует.

Сообщение от Fulcrum_013 НУ вы же сами сказали - только вручную. Т.е. GC бесполезен в плане уборки мусора.

Я сказал только про этот редкий случай. Не надо раздувать отдельный случай до всей практики использования GC.

0

Сообщение от Usaga Ещё раз для повторюсь, что такая практика дико редка, если вообще применяется.

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

Добавлено через 6 минут

Сообщение от Usaga Я сказал только про этот редкий случай

К примеру в САПР других случаев просто не бывает. В геймдеве тоже. В UI фреймверках и CURD тем более - тут датабиндинг вообще на каждом шагу. Так что на самом деле редкий случай это то где вообще GC применим. А где не заменим более эффективными средствами - так такой случай только один и тот никто никогда не пользует, потому что строительство иерархий из примитивных пассивных хранилищ данных осталось в 60-ых годах прошлого века.

Добавлено через 16 минут

Сообщение от Usaga Сиюсекундные обновления крайне редко где нужны.

Вообще то нужны обновления по инициативе источника. Это гораздо более эффективный подход чем спамить источник/сервер запросами на обновление. А вот именно для этого нужна ссылка со стороны источника. При этом это такой подход позволяет еще и копий не плодить. Датабиндинг подразумевает как обновление данных источника по инициативе формы так и формы по инициативе источника. А из всего остального биндинг как из говна пуля.

0

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

Нет, она мало где. Даже в серьёзном CRUD. И не нужно приплетать всякую фигню и обвинения в непрофессионализме. GC - инструмент хороший и практичный. Это вы у нас тут доказательств нормальных (обратного) привести не смогли. Напомню вам: начинали вы с того, что приложение с GC вообще работать не будет. А сейчас уже вы вокруг одного сценария сосредоточились, где вручную ссылки врать надо и всё. И то, что в данном случае, помешает использовать WeakReference? Как уж вертитесь под ногой.

Сообщение от Fulcrum_013 К примеру в САПР других случаев просто не бывает. В геймдеве тоже. В UI фреймверках и CURD тем более - тут датабиндинг вообще на каждом шагу. Так что на самом деле редкий случай это то где вообще GC применим. А где не заменим более эффективными средствами - так такой случай только один и тот никто никогда не пользует, потому что строительство иерархий из примитивных пассивных хранилищ данных осталось в 60-ых годах прошлого века.

Не рассказывайте мне про UI фреймворки. Я не первый день с ними работаю. И до сих пор ни разу не приходилось ссылки обнулять, хотя и байндинги использую и обновление информации (справочники) и всё остальное. Почему так? Ведь из ваших рассуждений следует, что наша ИС должна падать с OutOfMemoryException уже через пару минут. Но этого не происходит. Почему? Опять обвините в том, что наше приложение - HelloWorld?))

Сообщение от Fulcrum_013 Вообще то нужны обновления по инициативе источника. Это гораздо более эффективный подход чем спамить источник/сервер запросами на обновление. А вот именно для этого нужна ссылка со стороны источника. При этом это такой подход позволяет еще и копий не плодить. Датабиндинг подразумевает как обновление данных источника по инициативе формы так и формы по инициативе источника. А из всего остального биндинг как из говна пуля.

Инициатива источника не подразумевает ссылку на КАЖДЫЙ из таких источников. Для формы источник может быть один - ViewModel, который выступит агрегатором событий от этих источников. Для формы это будет всего лишь одна связь. Одна, Карл! Это вообще никак не мешает использовать GC. Вообще, Карл!

0