CC>Убери break и получится совсем другое, но тем не менее легальное и часто используемое поведение.
Легальное, да (потому что обратная совместимость), часто используемое — отнюдь. Такое использование вообще не особо одобряется, в силу особенностей чтения этих макарошек из goto
CC>Тем не менее refactor rename всех имён на более длинные багов не добавит.
Так и строк не добавит.
CC>Ну вон perl преуспел в уменьшении колва буковок, но это только добавило ему зубодробительной нечитабельности.
У Perl проблемы были не (только) с этим.
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, gandjustas, Вы писали:
G>Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств. G>В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.
А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от
тех же set_,get_ в яве, сгенеренных ORM?
Кодом людям нужно помогать!
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, so5team, Вы писали:
S>Мне вот правда интересно, что люди пишут на языках высокого уровня такого, что им не нужны генерики/шаблоны. S>Когда про ненужность обобщенного программирования говорят старые системные программисты или хардкорные embeddede-разработчики, которые вынуждены ужимать все в 32KiB, то их понять еще можно. Но вот за пределами этой специфической ниши... S>Да даже в Go, который создавался для совсем уж необучаемых даунов, генерики в итоге завезли (при этом про надобность такой фичи авторам Go говорили все кому не лень чуть ли не с самого начала). S>А тут образец -- это Java до добавления генериков S>Вот как так?
Попробую додумать за vsb, правда, оговрюсь, что на яве я не писал. Так вот, у них дженерики были крайне плохо
реализованы через type erasure (1ая ссылка гугля). Т.е. компилятор
чего-то там генерил, удалял и т.п. run-time про дженерики ничего не знал. Т.е. вроде бы есть, а вроде бы лучше
чтобы и не было. Наверное, это имелось в виду. А по уму они сделаны с C# 2.0, например, когда run-time отменно знал
про такое расширение типов и компилятору не надо было приседать.
Кодом людям нужно помогать!
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, 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,
}
Здравствуйте, 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.
S>На уровне clr нету никаких св-в, там есть соотв. методы.
В метаданных свойства есть
S>Так и будет компилироватсья в sql.
Пока неясно
S>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.
в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?
Bind в обе стороны работает.
Собственно наличие метаданных свойств и позволяет делать всякие привязки и мэппинги. А синтаксис свойств не позволяет написать пару методов на которых мэппинги не сработают. Так что это чуть больше, чем просто синтаксический сахар
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Sharov, Вы писали:
S>>А тут образец -- это Java до добавления генериков S>>Вот как так?
S>Попробую додумать за vsb
Я, к сожалению, так и не понял, что не так к генериками по мнению vsb.
S>правда, оговрюсь, что на яве я не писал.
Так разговор же к Java не был привязан.
Могу лишь предположить, что по мнению vsb генерики/шаблоны гораздо в большей степени нужны разработчикам библиотек. Ну, типа, написать обобщенный map или zip без генериков/шаблонов не получится. Придется как в древних версиях Java или Object Pascal оперировать базовым Object-ом, в котором должны быть соответствующие виртуальные методы, либо же в реализации придется вручную делать касты от Object-а к каким специализированным интерфейсам. Так что разработчикам библиотек средства для нормального обобщенного программирования очень нужны.
Тогда как прикладные программисты, которые педалят скучную бизнес-логику, писать обобщенный код особо негде. Поэтому от наличия или отсутствия генериков/шаблонов в языке прикладному программисту, которому нужно написать чтение очередной порции данных из БД и отдать куда-то в JSON-е, ни тепло, ни холодно.
Подозреваю, что позицию vsb следует понимать как-то так.
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Sharov, Вы писали:
G>>2) Как потом оно будет компилироваться в SQL ? S>На уровне clr нету никаких св-в
В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует. Во-вторых этот пример про expression tree, там код не компилируется до IL, а преобразуется в построение AST, которое потом интерпретируется в рантайме. Так что что там знает clr в данном примере совершенно неважно.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, so5team, Вы писали:
S>Могу лишь предположить, что по мнению vsb генерики/шаблоны гораздо в большей степени нужны разработчикам библиотек. Ну, типа, написать обобщенный map или zip без генериков/шаблонов не получится. Придется как в древних версиях Java или Object Pascal оперировать базовым Object-ом, в котором должны быть соответствующие виртуальные методы, либо же в реализации придется вручную делать касты от Object-а к каким специализированным интерфейсам. Так что разработчикам библиотек средства для нормального обобщенного программирования очень нужны.
S>Тогда как прикладные программисты, которые педалят скучную бизнес-логику, писать обобщенный код особо негде. Поэтому от наличия или отсутствия генериков/шаблонов в языке прикладному программисту, которому нужно написать чтение очередной порции данных из БД и отдать куда-то в JSON-е, ни тепло, ни холодно.
Это популярное мнение из Го. Но есть аспекты, о которых часто умалчивают.
1) Быстродействие и потребление памяти. Предположим мы создаем необобщенную структуру данных. Тогда каждый элемент у нас — ссылка на объект. Этот объект должен размещаться в куче, под него надо выделить память, он должен быть обработан сборщиком мусора. Даже если размер объекта сопоставим с размером указателя, хранимым в структуре. Генерики позволяют создавать структуры где объекты (структуры) хранятся по месту и не требуют дополнительных аллокаций.
2) Без генериков невозможно функциональное программирование, так как большинство комбинаторов — функций, выполняющих небольшую часть работы, которые можно последовательно применять к результатам вызовов других комбинаторов — невозможно описать без обобщённых типов и лямбда-функций. Без ФП код прикладной программы становится более многословным и повторяющимся. Это касается даже простого кода, который перекладывает JSON туда-сюда.
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, 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?
Т.е. я согласен, что св-ва многое упрощают и т.д. Я не пониманию, почему св-ва делют что-то концептуально
возможным. Блин, это же сахар, в конце концов.
Кодом людям нужно помогать!
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Ночной Смотрящий, Вы писали:
G>>>2) Как потом оно будет компилироваться в SQL ? S>>На уровне clr нету никаких св-в НС>В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует.
См. выше мой ответ.
НС> Во-вторых этот пример про expression tree, там код не компилируется до IL, а преобразуется в построение AST, которое потом интерпретируется в рантайме. Так что что там знает clr в данном примере совершенно неважно.
Вопрос хороший, но я опять же не понимаю, почему вместо prop_X нельзя get_X. Более того, отвечу от противного --
а как у ява c Hibernate все это дело работает? Как-то же работает.
Кодом людям нужно помогать!
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
Что именно? Для генерации кода или обработки кода через Roslyn в том же SourceGenerator удобнее оперировать свойствами, чем методами.
А методы свойств по умолчанию инлайнятся. То скорость доступа к полю или свойству одинаков S>>Свойства оочень удобны. Особенно после Явы.
S>Я не спорю. Просто какую концептуальную возможность они добавили. Сахар просто что-то упрощает, S>а не делает концептуально возможным.
Ну прежде всего это Reflection и обработка кода через Roslyn или прочие парсеры и модификаторы кода.
Вот например атрибуты это сахар?
и солнце б утром не вставало, когда бы не было меня
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, 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 в генериках разбираются плохо. И это проблема языка.
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, 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 файле. И который потом связывается с джавовским классом при помощи рефлекшен-магии.