Здравствуйте, Pauel, Вы писали:
S>> XAML это про декларативность. То есть за строкой скрывается куча кода.
P>Именно это и есть в моем примере
Нет это конструкторы. Ты явно не использовал XAML S>> Ну а в приведённом тобой коде это экономия на new.
P>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте
Здравствуйте, Sinclair, Вы писали:
S>Давайте возьмём более-менее любую популярную библиотеку и посмотрим, сколько конструкторов у привычных нам объектов. S>Например, какой-нибудь FileStream. Или тот же DateTime.
DateTime плохой пример. DateTimeOffset — 8 конструкторов. Я в свое время задолбался писать конформанс тесты под один из сервисов на дотнете и джаве — у них вечно были ошибки с рендерингом выхлопа с датами.
Визуально, по коду, разницы между двумя вариантами почти что нет — код ревью не работает. А покрыть тестами все нюансы со временем мягко говоря задача не маленькая.
S>А в-четвёртых, если вы хотите посмотреть на приложение, в котором на таком месте задаётся структура типа DOM, то запустите Visual Studio. S>Там весь редактор кода — это иммутабельное дерево поверх иммутабельного дерева. S>И все инспекторы и codefix-провайдеры работают с этим иммутабельным деревом именно через всякие root.ReplaceNode(classDeclaration, classDeclaration.AddModifiers(items)). S>Вполне себе всё это шустро работает, и GC им не мешает .
Подозреваю, они напилили там целую кучу оптимизаций под гц, что бы не было лишних переаллокаций. В 00х у них было полно проблем с перформансом, память могла уходить гигабайтами на ровном месте. Потом вероятно привели всё в порядок.
Здравствуйте, Serginio1, Вы писали:
P>>Именно это и есть в моем примере S>Нет это конструкторы. Ты явно не использовал XAML
Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно
Сам по себе XAML не летает — это просто фронтенд для описания структуры.
А далее готовая структура подаётся в бакенд, который её интерпретирует.
Декларативные свойства обеспечивают не xaml, а тот самый бакенд.
Собственно, вместо XAML вы можете использовать что угодно, абы структура на выходе была такая же.
Вы можете и сейчас это сделать разными путями
1. создавать структуру на основе более внятного ДСЛ, нежели xaml, транслируюя в xaml
2. императивно
3. на основе инциализаторов, которые кривые, что вы и продемонстрировали
То есть, буде в наличии внятные инциализаторы, нет необходимости городить огород из XAML
S>>> Ну а в приведённом тобой коде это экономия на new.
P>>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте
S>bkb S>
Здравствуйте, Pauel, Вы писали:
P>>>Именно это и есть в моем примере S>>Нет это конструкторы. Ты явно не использовал XAML
P>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно
Там есть конвертеры, тригеры итд.
Я шарпом занимаюсь с 2002 года. И сначала XAML у меня вызвал отвращение.
Да я и не особо дизайнер.
P>Сам по себе XAML не летает — это просто фронтенд для описания структуры. P>А далее готовая структура подаётся в бакенд, который её интерпретирует.
Ну вообще то он компилируется Компиляция XAML
P>Декларативные свойства обеспечивают не xaml, а тот самый бакенд. P>Собственно, вместо XAML вы можете использовать что угодно, абы структура на выходе была такая же. P>Вы можете и сейчас это сделать разными путями P>1. создавать структуру на основе более внятного ДСЛ, нежели xaml, транслируюя в xaml P>2. императивно P>3. на основе инциализаторов, которые кривые, что вы и продемонстрировали
P>То есть, буде в наличии внятные инциализаторы, нет необходимости городить огород из XAML
Я так же программно иногда делаю.
Но это от лени. Я не так часто его использую.
S>>>> Ну а в приведённом тобой коде это экономия на new.
P>>>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте
S>>bkb S>>
P>Итого — по вашему коду не сильно видна разница между объектами и списками, + шум new()
Ну можно
list = new List<object>
а new кому то шум, а кому то явное определение
P>Кроме того, у вас вероятно ошибка P>Вот здесь создаем список у которого два элемента, один с типом ItemA, второй ItemB P>
new ItemA() {id= 'a', content= yyy },
new ItemB() {id= 'a', content= zzz },
или если есть конструктор с параметрами id и content
new ItemA(id: 'a', content: yyy),
new ItemB(id: 'a', content: zzz ),
Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.
Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
P>>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно S>Там есть конвертеры, тригеры итд.
Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml
P>>Сам по себе XAML не летает — это просто фронтенд для описания структуры. P>>А далее готовая структура подаётся в бакенд, который её интерпретирует.
S> Ну вообще то он компилируется Компиляция XAML
И что с того? Это всё равно описание структуры. Всю работу делает бакенд.
Во что именно xaml компилируется, в вызовы типа "parent.addElement(...)" ? Если так, то никаких преимуществ перед инициализаторами нет.
Если во чтото более низкоуровневое — тут слабо верится.
S> Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть. S>Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов
Подозреваю, в микрософте была идея, что над кодом будут работать дизайнеры и программисты
А прогресс пошел по другому пути — начали плодиться разрешения от 320x200 до 8K, десятками тысяч и дизайнерам уже было не до кода — успеть бы картинок нарисовать.
Лайоут типа респонзив итд у микрософта был непредусмотрен, соответсвенно видение микрософта умерло вместе с ихними инструментами для рисования ui.
Для ui разработчиков нужно максимальное разделение концепций — отделить даные, лайоут, стили, рендеринг и поведение.
То есть вот такой стек у нас выходит
1 данные
2 семантический рендеринг
3 стили
4 лайоут, композиция
5 реакция и поведение
технически 4 и 3 делают одним и тем же инструментом, но реально это трохи разные вещи. стили это look & feel, layout это взаимодействие элементов
У микрософта 2, 3 и 4 это Винигрет, до кучи многословный
Вещи из п1-5 могут деливериться каждый по отдельности, буквально. До момента деплоя вы можете никогда не видеть вон те стили и вон тот лайоут на тех данных с таким вот поведением.
Почему так произошло — потому что спрос на фронтенд всё время растет, фронтенд становится сложнее с т.з. требований. А раз растет сложность требований, то очевидно и внутренняя структура будет меняться точно так же — будет усложняться.
Здравствуйте, Pauel, Вы писали:
P>>>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно S>>Там есть конвертеры, тригеры итд.
P>Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml
XAML это в том числе и визуальный редактор. Ты сразу видишь результат, интеллисенс итд.
P>>>Сам по себе XAML не летает — это просто фронтенд для описания структуры. P>>>А далее готовая структура подаётся в бакенд, который её интерпретирует.
S>> Ну вообще то он компилируется Компиляция XAML
P>И что с того? Это всё равно описание структуры. Всю работу делает бакенд. P>Во что именно xaml компилируется, в вызовы типа "parent.addElement(...)" ? Если так, то никаких преимуществ перед инициализаторами нет. P>Если во чтото более низкоуровневое — тут слабо верится.
Ну вот в то, что ты пишешь вручную без редактора.
S>> Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть. S>>Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов
P>Подозреваю, в микрософте была идея, что над кодом будут работать дизайнеры и программисты P>А прогресс пошел по другому пути — начали плодиться разрешения от 320x200 до 8K, десятками тысяч и дизайнерам уже было не до кода — успеть бы картинок нарисовать. P>Лайоут типа респонзив итд у микрософта был непредусмотрен, соответсвенно видение микрософта умерло вместе с ихними инструментами для рисования ui.
P>Для ui разработчиков нужно максимальное разделение концепций — отделить даные, лайоут, стили, рендеринг и поведение.
P>То есть вот такой стек у нас выходит P>1 данные P>2 семантический рендеринг P>3 стили P>4 лайоут, композиция P>5 реакция и поведение
P>технически 4 и 3 делают одним и тем же инструментом, но реально это трохи разные вещи. стили это look & feel, layout это взаимодействие элементов
P>У микрософта 2, 3 и 4 это Винигрет, до кучи многословный
P>Вещи из п1-5 могут деливериться каждый по отдельности, буквально. До момента деплоя вы можете никогда не видеть вон те стили и вон тот лайоут на тех данных с таким вот поведением.
P>Почему так произошло — потому что спрос на фронтенд всё время растет, фронтенд становится сложнее с т.з. требований. А раз растет сложность требований, то очевидно и внутренняя структура будет меняться точно так же — будет усложняться.
Фронтэнд это для браузеров. Для десктопа нужны другие инструменты.
Но, что я не вижу особо альтернатив. Может XAML заменить на YAML.
Суть она должна быть удобна для дизайнеров. Но прошло столько лет, а XAML никуда не делся.
Тот же MAUI на XAML
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
P>>Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml S>XAML это в том числе и визуальный редактор. Ты сразу видишь результат, интеллисенс итд.
Такой редактор можно прикрутить к чему угодно — такое понаписывали чуть ли не на все случаи жизни, наверное на всех языках есть
Инициализаторы это json подобный язык — проще просто некуда
У xaml сверх этого нет ни единого преимуществе
Apple вон вовсе выдал SwiftUI — шикарная вещь. Может не самая идеальная, но уж точно лучше xaml
P>>Если во чтото более низкоуровневое — тут слабо верится. S> Ну вот в то, что ты пишешь вручную без редактора.
не смешите людей — редактор даже на основе тупого кода в winforms прикрутили, а вы трясетесь, что json подобный язык вдруг станет препятствием
S>Суть она должна быть удобна для дизайнеров. Но прошло столько лет, а XAML никуда не делся.
Дизайнеры с кодом не работают. Им не до этого — задача дизайнера не xaml выдать, а нарисовать картинки на все случаи жизни, размеры экрана итд.
XAML никуда не делся потому, что его чисто технически нечем заменить
1. в языке нет ничего внятного, что может послужить заменой
2. в рантайме хилые средства, приходится мастырить грабли типа attached property, конвертеры, триггеры итд.
> Для десктопа нужны другие инструменты.
Очень смешно — софта на веб-технологиях появляется всё больше. pva стали нормой. electron прижился. сапр и те потиху идут в веб.
Чисто десктопный софт теперь это узенькая ниша инструментов которые идут вместе с системой.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>C++. _NN>>&& означает, что функция может применяться исключительно к временному объекту.
S> Вот же извращенцы! И до такого надо ещё додуматься! S>А почему не в конструкторе?
В чём собственно вопрос ?
C++ позволяет гибко указать когда функция может применяться к объекту:
Компиляторы — крайне фиговый пример, потому что специфика в полный рост, причем специфика такая, что нигде больше в больших объемах не встречается.
А так да, на компиляторах ФП максимально демонстрирует свои преимущества. А вот если брать мейнстримовый мейнстрим, то на тех же задачках из области CRUD (и в целом на задачах, в которых несколько моделей с преобразованиями) все становится совсем не очевидным.
Здравствуйте, vsb, Вы писали:
vsb>ООП это когда данные и функции объединяются в одну сущность.
Это, скажем так, не единственное и даже не так чтобы основное.
Основное отличие — идеологическое. ООП это декомпозиция на модели, а ФП — на функции. Т.е. ООП описывает дизайн софта как набор графов из разнотипных узлов со связями и ассоциированными с узлами методов, а ФП как одну большую функцию, которая является композицией функций поменьше.
vsb>Подходы друг с другом никак не пересекаются и одно другому никак не мешает.
Некоторое пересечение все же есть, хотя бы потому что для одной задачи обычно существует как функциональное, так и ООП решение.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, _NN_, Вы писали:
_NN>>>C++. _NN>>>&& означает, что функция может применяться исключительно к временному объекту.
S>> Вот же извращенцы! И до такого надо ещё додуматься! S>>А почему не в конструкторе?
_NN>В чём собственно вопрос ? _NN>C++ позволяет гибко указать когда функция может применяться к объекту:
Здравствуйте, Serginio1, Вы писали: S> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.
S>VMT! Интерфейсы! Видимость свойств и методов.
VMT — это деталь реализации. Можно строить ООП существенно по-другому.
В том же Object Pascal (aka Delphi) есть две разных VMT. S> Ref тоже могут быть read only readonly ref S>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
Не в этом дело. S> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
Чтобы это было можно,
а) элементы массива должны быть ссылками
б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
Получаем, собсно, reference type aka class.
Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение. S>Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.
В Delphi интересно сделали поддержку интерфейсов. Делали отдельную VMT для каждого объекта где перед вызовом метода корректировался Self.
В COM нет полей, но есть VMT.
S>>VMT! Интерфейсы! Видимость свойств и методов. S>VMT — это деталь реализации. Можно строить ООП существенно по-другому. S>В том же Object Pascal (aka Delphi) есть две разных VMT.
На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override Нужны ли метаклассы????1 S>> Ref тоже могут быть read only readonly ref S>>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов. S>Не в этом дело. S>> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++ S>Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность. S>Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр. S>То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct(). S>Чтобы это было можно, S>а) элементы массива должны быть ссылками S>б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает. S>Получаем, собсно, reference type aka class. S>Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке. S>То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Ну вот С++ прекрасно себе используют структуры и не кашляют.
Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override https://stackoverflow.com/questions/15416733/what-is-the-difference-between-dynamic-and-virtual-methods
S> Ну вот С++ прекрасно себе используют структуры и не кашляют.
В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте. S>Можно создать ограничения итд. А так приходится наследоваться через Агрегирование. S> Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
Это просто реализация COM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override S>https://stackoverflow.com/questions/15416733/what-is-the-difference-between-dynamic-and-virtual-methods
S>> Ну вот С++ прекрасно себе используют структуры и не кашляют. S>В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте.
Боксинг структуры это тот же объект. А что касается стеков и массивов, то все там хранится в явном виде. S>>Можно создать ограничения итд. А так приходится наследоваться через Агрегирование. S>> Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса S>Это просто реализация COM.
А что мешает это присобачить к структурам?
То есть это не интерфейс, а просто автогенерация методов, которое можно сделать через SG, а конфликты решать через атрибуты
И соответственно сделать доступ к protected полям
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте. S> Боксинг структуры это тот же объект. А что касается стеков и массивов, то все там хранится в явном виде.
В том-то и дело. Как будет устроен layout массива структур в таком случае?
Будет ли массив структур ковариантен, как массив ссылочных типов?
S> А что мешает это присобачить к структурам?
Отсутствие у них VMT. S> То есть это не интерфейс, а просто автогенерация методов, которое можно сделать через SG, а конфликты решать через атрибуты S> И соответственно сделать доступ к protected полям
Теоретически можно это навелосипедить, но вы получите обратно reference-типы.
В чём тогда смысл "структурности"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте. S>> Боксинг структуры это тот же объект. А что касается стеков и массивов, то все там хранится в явном виде. S>В том-то и дело. Как будет устроен layout массива структур в таком случае? S>Будет ли массив структур ковариантен, как массив ссылочных типов?
S>> А что мешает это присобачить к структурам? S>Отсутствие у них VMT.
Еще раз наследование для структур это не VMT это наследование полей свойств и методов.
Это наследование без виртуальных методов. Для структур это запрещено!
S>> То есть это не интерфейс, а просто автогенерация методов, которое можно сделать через SG, а конфликты решать через атрибуты S>> И соответственно сделать доступ к protected полям S>Теоретически можно это навелосипедить, но вы получите обратно reference-типы. S>В чём тогда смысл "структурности"?
Как я и писал выше это обычное наследование, но без виртуальных методов
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S>>> А что мешает это присобачить к структурам? S>>Отсутствие у них VMT. S> Еще раз наследование для структур это не VMT это наследование полей свойств и методов. S>Это наследование без виртуальных методов. Для структур это запрещено!
Какой сценарий в прикладном коде выиграет от наследования с такими ограничениями?
Наследование ценно там, где экземпляр субтипа может выступать в качестве супертипа.
А в нашем случае что?
Вот у нас
public struct Name
{
public Name: string;
}
public class Person
{
public Name: Name;
}
А теперь мы хотим применить наследование:
public struct FullName: Name
{
// Name: string is inheritedpublic LastName: string;
}
...
var p = new Person();
p.Name = new FullName {Name = "John", FullName = "Doe"}
Что будет происходить? Молчаливое урезание FullName до Name? Ошибка компиляции?
Единственное место, где FullName можно относительно безопасно использовать вместо Name — это ref Name аргумент в какую-нибудь функцию. Ну, или в ref-поле ref-структуры — то есть, опять же, конструкции, которая может жить исключительно на стеке.
И то, непонятно, как GC будет отслеживать ссылки — ему ведь нужно как-то понимать, что в данном экземпляре Person через Name.LastName прикопана ссылка на строку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.