CC>Убери break и получится совсем другое, но тем не менее легальное и часто используемое поведение.

Легальное, да (потому что обратная совместимость), часто используемое — отнюдь. Такое использование вообще не особо одобряется, в силу особенностей чтения этих макарошек из goto

CC>Тем не менее refactor rename всех имён на более длинные багов не добавит.

Так и строк не добавит.

CC>Ну вон perl преуспел в уменьшении колва буковок, но это только добавило ему зубодробительной нечитабельности.

У Perl проблемы были не (только) с этим.

Здравствуйте, gandjustas, Вы писали:

G>Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.
G>В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.

А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от
тех же set_,get_ в яве, сгенеренных ORM?

Здравствуйте, so5team, Вы писали:

S>Мне вот правда интересно, что люди пишут на языках высокого уровня такого, что им не нужны генерики/шаблоны.
S>Когда про ненужность обобщенного программирования говорят старые системные программисты или хардкорные embeddede-разработчики, которые вынуждены ужимать все в 32KiB, то их понять еще можно. Но вот за пределами этой специфической ниши...
S>Да даже в Go, который создавался для совсем уж необучаемых даунов, генерики в итоге завезли (при этом про надобность такой фичи авторам Go говорили все кому не лень чуть ли не с самого начала).
S>А тут образец -- это Java до добавления генериков
S>Вот как так?

Попробую додумать за vsb, правда, оговрюсь, что на яве я не писал. Так вот, у них дженерики были крайне плохо
реализованы через type erasure (1ая ссылка гугля). Т.е. компилятор
чего-то там генерил, удалял и т.п. run-time про дженерики ничего не знал. Т.е. вроде бы есть, а вроде бы лучше
чтобы и не было. Наверное, это имелось в виду. А по уму они сделаны с C# 2.0, например, когда run-time отменно знал
про такое расширение типов и компилятору не надо было приседать.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.
G>>В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.

S>А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от
S>тех же set_,get_ в яве, сгенеренных ORM?

Пример номер раз:

var query = from x in db.Table
            select new Projection {
                X1 = x.Y1,
                X2 = x.Y2,
                X3 = x.Y3 - x.Y1,
            }

1) Это это можно переписать без свойств?
2) Как потом оно будет компилироваться в SQL ?

var query = from x in db.Table
            select new Projection {
                X1 = x.Y1,
                X2 = x.Y2,
                X3 = x.Y3 - x.Y1,
            }

Пример номер два (Blazor)

@page "/bind"

<p>
    <input @bind="InputValue" />
</p>

@code {

    private string? InputValue { get; set; }
}

Как сделать проверку типа привязки во время набора кода, если вместо свойства у нас пара функций?

Здравствуйте, gandjustas, Вы писали:

S>>А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от
S>>тех же set_,get_ в яве, сгенеренных ORM?
G>Пример номер раз:
G>

G>var query = from x in db.Table
G>            select new Projection {
G>                X1 = x.Y1,
G>                X2 = x.Y2,
G>                X3 = x.Y3 - x.Y1,
G>            }
G>

G>1) Это это можно переписать без свойств?

foreach(var x in db.Table)
{
 var prj = new Projection();
 prj.set_Y1(x.Y1);
 ....  
}

G>2) Как потом оно будет компилироваться в SQL ?

На уровне clr нету никаких св-в, там есть соотв. методы. Так и будет компилироватсья в sql.


G>Пример номер два (Blazor)
G>

G>@page "/bind"

G><p>
G>    <input @bind="InputValue" />
G></p>

G>@code {

G>    private string? InputValue { get; set; }
G>}
G>

G>Как сделать проверку типа привязки во время набора кода, если вместо свойства у нас пара функций?

Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.
в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?

Здравствуйте, Sharov, Вы писали:


S>На уровне clr нету никаких св-в, там есть соотв. методы.
В метаданных свойства есть

S>Так и будет компилироватсья в sql.
Пока неясно


S>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.
в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?

Bind в обе стороны работает.

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

Здравствуйте, Sharov, Вы писали:

S>>А тут образец -- это Java до добавления генериков
S>>Вот как так?

S>Попробую додумать за vsb

Я, к сожалению, так и не понял, что не так к генериками по мнению vsb.

S>правда, оговрюсь, что на яве я не писал.

Так разговор же к Java не был привязан.

Могу лишь предположить, что по мнению vsb генерики/шаблоны гораздо в большей степени нужны разработчикам библиотек. Ну, типа, написать обобщенный map или zip без генериков/шаблонов не получится. Придется как в древних версиях Java или Object Pascal оперировать базовым Object-ом, в котором должны быть соответствующие виртуальные методы, либо же в реализации придется вручную делать касты от Object-а к каким специализированным интерфейсам. Так что разработчикам библиотек средства для нормального обобщенного программирования очень нужны.

Тогда как прикладные программисты, которые педалят скучную бизнес-логику, писать обобщенный код особо негде. Поэтому от наличия или отсутствия генериков/шаблонов в языке прикладному программисту, которому нужно написать чтение очередной порции данных из БД и отдать куда-то в JSON-е, ни тепло, ни холодно.

Подозреваю, что позицию vsb следует понимать как-то так.

Здравствуйте, Sharov, Вы писали:

G>>2) Как потом оно будет компилироваться в SQL ?
S>На уровне clr нету никаких св-в

В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует. Во-вторых этот пример про expression tree, там код не компилируется до IL, а преобразуется в построение AST, которое потом интерпретируется в рантайме. Так что что там знает clr в данном примере совершенно неважно.

Здравствуйте, so5team, Вы писали:

S>Могу лишь предположить, что по мнению vsb генерики/шаблоны гораздо в большей степени нужны разработчикам библиотек. Ну, типа, написать обобщенный map или zip без генериков/шаблонов не получится. Придется как в древних версиях Java или Object Pascal оперировать базовым Object-ом, в котором должны быть соответствующие виртуальные методы, либо же в реализации придется вручную делать касты от Object-а к каким специализированным интерфейсам. Так что разработчикам библиотек средства для нормального обобщенного программирования очень нужны.

S>Тогда как прикладные программисты, которые педалят скучную бизнес-логику, писать обобщенный код особо негде. Поэтому от наличия или отсутствия генериков/шаблонов в языке прикладному программисту, которому нужно написать чтение очередной порции данных из БД и отдать куда-то в JSON-е, ни тепло, ни холодно.

Это популярное мнение из Го. Но есть аспекты, о которых часто умалчивают.
1) Быстродействие и потребление памяти. Предположим мы создаем необобщенную структуру данных. Тогда каждый элемент у нас — ссылка на объект. Этот объект должен размещаться в куче, под него надо выделить память, он должен быть обработан сборщиком мусора. Даже если размер объекта сопоставим с размером указателя, хранимым в структуре. Генерики позволяют создавать структуры где объекты (структуры) хранятся по месту и не требуют дополнительных аллокаций.
2) Без генериков невозможно функциональное программирование, так как большинство комбинаторов — функций, выполняющих небольшую часть работы, которые можно последовательно применять к результатам вызовов других комбинаторов — невозможно описать без обобщённых типов и лямбда-функций. Без ФП код прикладной программы становится более многословным и повторяющимся. Это касается даже простого кода, который перекладывает JSON туда-сюда.

Здравствуйте, gandjustas, Вы писали:

G>Это популярное мнение из Го. Но есть аспекты, о которых часто умалчивают.

Я описал лишь то, как я лично воспринял позицию vsb.
Это не значит, что сам я разделяю подобные взгляды.

Здравствуйте, LaptevVV, Вы писали:

LVV>Все, чего нет в Go — оно и не нужно.
LVV>Только усложняет язык.

в Go какой версии?

Ф>в Go какой версии?
До появления шаблонов...

Здравствуйте, Sharov, Вы писали:


S>На уровне clr нету никаких св-в, там есть соотв. методы. Так и будет компилироватсья в sql.

Угу а как же вызов свойства через рефлекшн?

public static object GetPropValue(object src, string propName)
 {
     return src.GetType().GetProperty(propName).GetValue(src, null);
 }

Тот же Roslyn https://stackoverflow.com/questions/38205773/how-to-create-struct-based-properties-with-roslyn
Для SourceGenerator
https://stackoverflow.com/questions/21316952/using-roslyn-for-c-how-do-i-get-a-list-of-all-properties-that-compose-a-return

Ну и инлайнинг методов свойства.

Свойства оочень удобны. Особенно после Явы.

Здравствуйте, gandjustas, Вы писали:

S>>На уровне clr нету никаких св-в, там есть соотв. методы.
G>В метаданных свойства есть

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

S>>Так и будет компилироватсья в sql.
G>Пока неясно

У меня будут вместо св-в генерироваться, допустим ORM, соотв. методы типа get_X. Дергать их.
Т.е. там, где исп. св-ва, что мешает исп. сгенерированные методы?

S>>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.
G>в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?
G>Bind в обе стороны работает.

Да, упустил. Ну опять же, кто-то это дело будет интерпритировать и у соотв. объекты вызывать соотв. методы get\set.


G>Собственно наличие метаданных свойств и позволяет делать всякие привязки и мэппинги. А синтаксис свойств не позволяет написать пару методов на которых мэппинги не сработают. Так что это чуть больше, чем просто синтаксический сахар

Все так. Я не понимаю, если в конце, на уровне clr, один хрен будут вызываться методы, то это просто
способо избавить программиста от лишнего кода или от сгенерированного кода. Т.е. св-ва -- это просто
упрощение, а не концептуальная возможность. В конце концов, как в яве то без св-в живут и сущ. ORM
типа NHibernate?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

G>>>2) Как потом оно будет компилироваться в SQL ?
S>>На уровне clr нету никаких св-в
НС>В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует.

См. выше мой ответ.

НС> Во-вторых этот пример про expression tree, там код не компилируется до IL, а преобразуется в построение AST, которое потом интерпретируется в рантайме. Так что что там знает clr в данном примере совершенно неважно.

Вопрос хороший, но я опять же не понимаю, почему вместо prop_X нельзя get_X. Более того, отвечу от противного --
а как у ява c Hibernate все это дело работает? Как-то же работает.

Здравствуйте, Serginio1, Вы писали:


S>>На уровне clr нету никаких св-в, там есть соотв. методы. Так и будет компилироватсья в sql.

S> Угу а как же вызов свойства через рефлекшн?
S>

S>public static object GetPropValue(object src, string propName)
S> {
S>     return src.GetType().GetProperty(propName).GetValue(src, null);
S> }
S>

Ну для спец. методов отдельный интерфейс, ну ок, и?

S> Тот же Roslyn https://stackoverflow.com/questions/38205773/how-to-create-struct-based-properties-with-roslyn
S>Для SourceGenerator
S>https://stackoverflow.com/questions/21316952/using-roslyn-for-c-how-do-i-get-a-list-of-all-properties-that-compose-a-return

S> Ну и инлайнинг методов свойства.

Не понял.

S>Свойства оочень удобны. Особенно после Явы.

Я не спорю. Просто какую концептуальную возможность они добавили. Сахар просто что-то упрощает,
а не делает концептуально возможным.

Здравствуйте, Sharov, Вы писали:


S>> Тот же Roslyn https://stackoverflow.com/questions/38205773/how-to-create-struct-based-properties-with-roslyn
S>>Для SourceGenerator
S>>https://stackoverflow.com/questions/21316952/using-roslyn-for-c-how-do-i-get-a-list-of-all-properties-that-compose-a-return

S>> Ну и инлайнинг методов свойства.

S>Не понял.

Что именно? Для генерации кода или обработки кода через Roslyn в том же SourceGenerator удобнее оперировать свойствами, чем методами.

А методы свойств по умолчанию инлайнятся. То скорость доступа к полю или свойству одинаков
S>>Свойства оочень удобны. Особенно после Явы.

S>Я не спорю. Просто какую концептуальную возможность они добавили. Сахар просто что-то упрощает,
S>а не делает концептуально возможным.

Ну прежде всего это Reflection и обработка кода через Roslyn или прочие парсеры и модификаторы кода.
Вот например атрибуты это сахар?

Здравствуйте, Sharov, Вы писали:

S>Попробую додумать за vsb, правда, оговрюсь, что на яве я не писал. Так вот, у них дженерики были крайне плохо
S>реализованы через type erasure (1ая ссылка гугля). Т.е. компилятор
S>чего-то там генерил, удалял и т.п. run-time про дженерики ничего не знал. Т.е. вроде бы есть, а вроде бы лучше
S>чтобы и не было. Наверное, это имелось в виду. А по уму они сделаны с C# 2.0, например, когда run-time отменно знал
S>про такое расширение типов и компилятору не надо было приседать.

С этим мнением я не согласен. Мне type erasure даже где-то нравится. Изящное решение. То, что рантайм про генерики не знает — может быть и кажется плохим, но на практике проблемы вызывает только в одном месте — иногда нужно прокидывать Class<T>. Но вот эту проблему прекрасно решает концепция reified generics в Kotlin. Компилятор в нужные места сам прокидывает рантайм тип скрытым параметром.

Не буду утверждать, что type erasure лучше, чем система из C#, у обоих подходов есть свои плюсы и минусы, наверное. Могу только утверждать, что ругают type erasure больше, чем он того заслуживает.

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

Мне не нравится само усложнение системы типов из-за генериков. Я сдавал в своё время сертификат sun и учил каждый нюанс в жаве. И генерики были самой сложной и запутанной темой. Я натыкался когда-то на баг в компиляторе javac. И баг был как раз связан с генериками. Я уверен, что 90% программистов на Java в генериках разбираются плохо. И это проблема языка.

Здравствуйте, gandjustas, Вы писали:

G>1) Быстродействие и потребление памяти. Предположим мы создаем необобщенную структуру данных. Тогда каждый элемент у нас — ссылка на объект. Этот объект должен размещаться в куче, под него надо выделить память, он должен быть обработан сборщиком мусора. Даже если размер объекта сопоставим с размером указателя, хранимым в структуре. Генерики позволяют создавать структуры где объекты (структуры) хранятся по месту и не требуют дополнительных аллокаций.

В Go это решается встроенными структурами данных и утверждением, что свои структуры данных нужны достаточно редко, чтобы это не было проблемой.

Если это вопрос жизни и смерти — ну напиши на C этот кусок программы.

G>2) Без генериков невозможно функциональное программирование, так как большинство комбинаторов — функций, выполняющих небольшую часть работы, которые можно последовательно применять к результатам вызовов других комбинаторов — невозможно описать без обобщённых типов и лямбда-функций. Без ФП код прикладной программы становится более многословным и повторяющимся. Это касается даже простого кода, который перекладывает JSON туда-сюда.

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

В общем обе эти проблемы решаются концепцией магических типов. Когда некоторые типы из стандартной библиотеки — коллекции, ну пусть даже какие-то функциональные типы, если так хочется — работают магическим образом и их невозможно повторить своим кодом. А какие-то кастомные коллекции и алгоритмы в 99% случаев не нужны. В тех 0.9% случаев, когда они нужны, они нужны исходя из алгоритмических соображений. Лишние переходы по указателям O-сложность хуже не сделают. И только в тех редчайших случаях, когда тебе нужен высший уровень производительности, язык не справится. Тогда надо просто спуститься на уровень ниже.

Здравствуйте, Sharov, Вы писали:

НС>>В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует.
S>См. выше мой ответ.

Это все неверно. Дело не в атрибутах, в метаданных есть прям такая сущность, свойство.

S>Вопрос хороший, но я опять же не понимаю, почему вместо prop_X нельзя get_X.

Можно. Но соответствие между геттером и сеттером компилятором при этом не проверяется. Т.е. свойство это не сахар, как Шимжа утверждал, а важный элемент системы типов. И замену системы типов на рефлекшен полноценной заменой никак нельзя назвать.

S> Более того, отвечу от противного -- а как у ява c Hibernate все это дело работает? Как-то же работает.

Фиговенько. Понадобилось вводить дополнительную сущность, Hibernate mapping types, которую надо отдельно описывать в xml файле. И который потом связывается с джавовским классом при помощи рефлекшен-магии.