Что нужно добавить в C#?
18.02.2013
|
AndrewVK |
Небольшое вступление.
Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь.
Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться.
Проголосовать за конкретные фичи можно здесь.
Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь.
Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться.
Проголосовать за конкретные фичи можно здесь.
... << RSDN@Home 1.2.0 alpha 5 rev. 23 on Windows 8 6.2.9200.0>>
18.02.2013 252 комментария |
KP>Все очень и очень просто: Java-way — работа на *NIX-ах из коробки
При чем тут компилятор шарпа? Это вопрос к CLR.
AVK>При чем тут компилятор шарпа? Это вопрос к CLR.
Ну, это как сказать. С одной стороны да. С другой стороны, CLR — это в первую очередь C#, так же как JVM это в первую очередь Java. Они неразрывно связанны и обсуждение одного в отрыве от второго бессмысленно.
KP>Ну, это как сказать.
Как ни говори — в контексте данного вопроса это точно обсуждать смысла нет.
KP>С другой стороны, CLR — это в первую очередь C#
Я бы так не сказал. В любом случае — изменения в CLR это уже точно революция, и это другая команда. И вообще это больше политика, нежели технический вопрос.
KP>Ну, это как сказать. С одной стороны да. С другой стороны, CLR — это в первую очередь C#, так же как JVM это в первую очередь Java. Они неразрывно связанны и обсуждение одного в отрыве от второго бессмысленно.
Наличие Mono как бы намекает, что вы ерунду говорите
Мне в Шарпе не хватает одной фичи из Немерле: foreach c индексатором, типа:
Здесь i номер текущей итерации.
DR>
DR>Здесь i номер текущей итерации.
А... раз пошла такая пьянка, то можно и остальные фичи из Немерла реализовать .
DR>Здравствуйте, AndrewVK, Вы писали:
DR>Мне в Шарпе не хватает одной фичи из Немерле: foreach c индексатором, типа:
DR>
DR>Здесь i номер текущей итерации.
в чем существенная польза? не так часто нужно, а если нужно то можно индексировать самому.
или я не так понял идею?
GH>в чем существенная польза? не так часто нужно, а если нужно то можно индексировать самому.
GH>или я не так понял идею?
Мне не так уж и редко приходится оборачивать foreach в ручную реализацию for. Вот несколько сценариев:
overquotingЗачем в языке делать то, что можно сделать в библиотеке?
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
Если брать мелочи, мне было бы интересно видеть более удобную работу со строками а-ля питон.
Вот например, (псевдо)код на питоне (копипаста из документации)
Потом можно прицениться к спискам
AVK>Небольшое вступление.
AVK>Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь.
AVK>Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться.
AVK>Проголосовать за конкретные фичи можно здесь.
Вряд ли скажу big thing, но мелкие доработки были бы очень даже неплохи. Сам начинал с C#, потом судьба забросила на Java, и могу сказать, что оба языка прекрасны, и всё же C#-у стоило бы позаимствовать некоторые Java-фишки.
Строгий типизированный "объектный" enum, как в Java 1.5. Здорово решают проблему хранение некоего "регистра" того или иного набора данных. В отличии от примитивных целочисленных констант в шарпе, в Java можно не хило так "полиморфировать" enum-константы, наделяя их реализациями интерфейсов, абстрактных методов, не говоря уже об обычных полях и методах. Небезысвестный Jon Skeet уже как семь лет назад говорил о таком. Компилятор справился бы с перечислениями, я думаю, без изменения CLR.
Возможно, пересмотреть всеобъемлющую директиву using, которая открывает иногда слишком много. В этом контексте я бы пересмотрел также импорт методов расширения, которые не пойми откуда появляются, а также добавил бы "статический импорт": после Java, с её возможностью импортирования статических методов и полей, Console.WriteLine() выглядит уродливо. И если с первыми двумя уже, скорее всего, уже ничего не поделать, то третье можно привинтить было бы.
Возможно, виртуальные методы расширения, как в Java 8 (единственное поведение по умолчанию для интерфейсов как бы "встраивается" без необходимости открывать методы расширения, реализация поведения которых зависит, в принципе, от того, что открыто). Но, наверно, это сомнительное пожелание в контексте уже существующих методов-расширений C#.
После анонимных классов в Java руки автоматически тянутся писать такое же и в C#-коде. Можно, конечно, часто обойтись делегатами, но анонимные классы в Java позволяют инкапсулировать состояние.
Сигнатурные ограничения для конструкторов обобщённых типов: не просто конструктор по умолчанию, а возможность указать желаемую сигнатуру конструктора объекта. Например, для инджектирования объекта через конструктор, а не через свойства -- раз и до конца жизни объекта.
Лично мне "as" не очень нравится. Может быть, такое:
вместо
Часто работаю с рефлексией на Java, но и там самая крутая возможность ссылаться на что-то без строки с именем, а по имени напрямую -- Type.class (typeof(Type) в C#). Иногда очень хочется такого и для методов (делегаты делают нечто похожее), полей и свойств. Таким образом рефакторинг таких вещей происходил бы менее болезненно.
И всякие плюшки в виде интерполированных строк, литералы для регулярок, этц, хотя это уже на любителя...
А если big thing, то, наверное, макросы.
Ц>литералы для регулярок
По поводу этого Мэдс сегодня сказал примерно следующее: You mean literal of the day?
AVK>По поводу этого Мэдс сегодня сказал примерно следующее: You mean literal of the day?
Есть "покруче".
Ц>Есть "покруче".
ААА! Вот откуда эту идею в Rust притащили
KP>ААА! Вот откуда эту идею в Rust притащили
В Немерле было раньше.
Ц>>Есть "покруче".
KP>ААА! Вот откуда эту идею в Rust притащили
Гы-гы (2005-й год). Думаю, что и до этого где-то было.
Ц>>>Есть "покруче".
KP>>ААА! Вот откуда эту идею в Rust притащили
VD>Гы-гы (2005-й год). Думаю, что и до этого где-то было.
В Perl было еще в прошлом веке.
Ц>Небезысвестный Jon Skeet уже как семь лет назад говорил о таком. Компилятор справился бы с перечислениями, я думаю, без изменения CLR.
При всем моем уважении к Скиту, его идея супернавороченных enum'ов мне не нравится. Что чаще всего надо? Парсинг и прочие конвертеры привязать к enum'у, чтобы не болтались в левых классах типа Utils. То есть, если иметь возможность добавить статические методы, этого более чем достаточно. Объявлять enum каким-то class enum совсем не надо. Ну, или, если хочется иметь методы .To(), можно сделать как в мутаторах — в контексте нестатических методов enum'а считать value ключевым словом.
Все остальное решается через наследование. Наследуйся, там добавишь все, что надо. Примерно, как от класса с одним целочисленным полем. Соответственно, доступ к значению через то же самое base.value.
А>При всем моем уважении к Скиту, его идея супернавороченных enum'ов мне не нравится. Что чаще всего надо? Парсинг и прочие конвертеры привязать к enum'у, чтобы не болтались в левых классах типа Utils. То есть, если иметь возможность добавить статические методы, этого более чем достаточно. Объявлять enum каким-то class enum совсем не надо. Ну, или, если хочется иметь методы .To(), можно сделать как в мутаторах — в контексте нестатических методов enum'а считать value ключевым словом.
А>Все остальное решается через наследование. Наследуйся, там добавишь все, что надо. Примерно, как от класса с одним целочисленным полем. Соответственно, доступ к значению через то же самое base.value.
Мутно как-то. В Java, кроме того, такие перечисления можно использовать в аннотациях (аттрибутах в терминологии C#).
Ц>Здравствуйте, Аноним, Вы писали:
А>>При всем моем уважении к Скиту, его идея супернавороченных enum'ов мне не нравится. Что чаще всего надо? Парсинг и прочие конвертеры привязать к enum'у, чтобы не болтались в левых классах типа Utils. То есть, если иметь возможность добавить статические методы, этого более чем достаточно. Объявлять enum каким-то class enum совсем не надо. Ну, или, если хочется иметь методы .To(), можно сделать как в мутаторах — в контексте нестатических методов enum'а считать value ключевым словом.
А>>Все остальное решается через наследование. Наследуйся, там добавишь все, что надо. Примерно, как от класса с одним целочисленным полем. Соответственно, доступ к значению через то же самое base.value.
Ц>Мутно как-то. В Java, кроме того, такие перечисления можно использовать в аннотациях (аттрибутах в терминологии C#).
Я не понимаю, что значит "мутно".
Я исхожу из реальной проблемы: часто встречаешь набор функций, которые относятся только к enum'у, но хостятся в классе Utils, Converters и т.п. Если их можно было бы засунуть в сам enum, было бы понятно:
Какие проблемы у Скита решаются с помощью class enum мне понять вообще не удалось.
То есть, я боюсь, что если и сделают енамы более объектными, то вместо маленького нужного инструмента зафигачат большой и ненужный. Если кому-то нужен класс и enum в одном флаконе, пусть пишет, как в PHP, то есть, класс с константами, с методами, конструкторами и прочим. А чтобы не копипастить код, когда уже есть enum, а свой такой класс надо построить на его базе, вполне достаточно поддержать наследование. И наследование самих enum'ов, конечно. Тоже не хватает, чтобы, допустим, от enum'а с секундой унаследовать как СИ, так и грамм-секундную систему. И чтобы секунда там и там была одной и той же.
А>Я исхожу из реальной проблемы: часто встречаешь набор функций, которые относятся только к enum'у, но хостятся в классе Utils, Converters и т.п. Если их можно было бы засунуть в сам enum, было бы понятно:
Решение не менее реальной проблемы на Java:
И внезапно в аннотациях/аттрибутах:
Что здесь плохого?
Ц>Что здесь плохого?
Не уверен, что я все понял правильно, и если нет, сразу простите дурака. Но если да, то это типичный пример ява-стайл ОООП'а (Over-engineered OOP), который меня просто убивает.
Плохо в этом примере то, что он скрывает неявное множественное наследование от System.Attribute и System.Enum.
Вообще, я за ООП в целом и множественное наследование в частности в каждом УЯП, но МН нужно таааааак редко... и это явно не тот случай. Пусть котлеты будут отдельно, а мухи — отдельно:
Обратите внимание на выделенное. Где ему место в вашем примере?
И раз уж речь зашла о нововведениях и Ските, то вот тут:
http://stackoverflow.com/questions/294216/why-does-c-sharp-forbid-generic-attribute-types
Скит пишет следующее:
Так что, если бы они ЭТО пофиксили, то ваш пример (именно ваш, без привязки к методам и с потенциальной неоднозначностью ролей) мог бы выглядеть так:
P.S. Чего мне в дотнете всегда не хватало, это набора стандартизированных интерфейсов, чтоб не пилить самому каждый раз, особенно в ремотных системах. System.EnumAttribute<T> это как раз из этой оперы.
Синтаксис Java может показаться непривычным и немножко сбивать с толку.
А>Не уверен, что я все понял правильно, и если нет, сразу простите дурака. Но если да, то это типичный пример ява-стайл ОООП'а (Over-engineered OOP), который меня просто убивает.
Пускай. Дело привычки, простоты повторного использования и издержек самой Java.
А>Плохо в этом примере то, что он скрывает неявное множественное наследование от System.Attribute и System.Enum.
Тут нет множественного наследования и не может такового быть. Перечисления неявно наследуются исключительно от java.lang.Enum<E>, хотя и имплементирует интерфейс. Пожалуй, я неудачно выбрал имена Role и RoleType? То, что вы, возможно, посчитали за наследование от System.Attribute -- аннотация @Role, аналог [RoleAttribute] (укажу ниже). Я здесь имел в виду то, что элемент такого перечисления может появляться в качестве значения аннотации. В .NET такое невозможно, насколько мне известно, и поэтому приходится довольствоваться только тем, что может быть константой (по поводу typeof не знаю, то в Java это считается константой, как и элемент перечисления). Могу ошибаться.
А>Обратите внимание на выделенное. Где ему место в вашем примере?
Я тогда просто хотел показать, что полноценный объект, хоть и с ограничениями enum и @interface на типы, а не простая целочисленная константа, может указываться в аннотации (аттрибута). Собственно, тогда уж и недостающий пример:
А>И раз уж речь зашла о нововведениях и Ските, то вот тут:
А>http://stackoverflow.com/questions/294216/why-does-c-sharp-forbid-generic-attribute-types
А>Скит пишет следующее:
А>...
@interface в Java тоже не может быть generic, как и enum. В моём случае перечисление просто обязуется реализовать параметризированный generic-интерфейс (для поиска члена перечисления не по имени, а по алиасу). Мне, честно говоря, сложно подобрать случай, в котором нужны generic-аттрибуты, когда из доступных значений аттрибутов могут быть только примитивы и строки.
overquotingА>То есть, я боюсь, что если и сделают енамы более объектными, то вместо маленького нужного инструмента зафигачат большой и ненужный. Если кому-то нужен класс и enum в одном флаконе, пусть пишет, как в PHP, то есть, класс с константами, с методами, конструкторами и прочим. А чтобы не копипастить код, когда уже есть enum, а свой такой класс надо построить на его базе, вполне достаточно поддержать наследование. И наследование самих enum'ов, конечно. Тоже не хватает, чтобы, допустим, от enum'а с секундой унаследовать как СИ, так и грамм-секундную систему. И чтобы секунда там и там была одной и той же.
Очень поддерживаю. Нужна возможность декларировать интерфейс создания семейства объектов.
X>Очень поддерживаю. Нужна возможность декларировать интерфейс создания семейства объектов.
Это просто идея, и я не уверен в её состоятельности. Я на самом деле очень люблю неизменяемые типы, но таким образом даже от левого класса нужна поддержка такого специфического конструирования объекта, хотя это забота уже самого типа. Поведение принято решать через методы интерфейсов. Быть может, здесь лучше использовать фабрику объектов, которая знает как создать неизменяемый объект?
Ц>Здравствуйте, xorets, Вы писали:
X>>Очень поддерживаю. Нужна возможность декларировать интерфейс создания семейства объектов.
Ц>Это просто идея, и я не уверен в её состоятельности. Я на самом деле очень люблю неизменяемые типы, но таким образом даже от левого класса нужна поддержка такого специфического конструирования объекта, хотя это забота уже самого типа. Поведение принято решать через методы интерфейсов. Быть может, здесь лучше использовать фабрику объектов, которая знает как создать неизменяемый объект?
Фабрика в этом случае — это лишний класс на пустом месте. Все правки шарпа как раз и нацелены на уменьшение количества "лишнего" кода.Так что считаю, что идея очень правильная. Сам тоже об этом думал: http://blogs.byte-force.com/xor/archive/2004/11/04/333.aspx
У меня еще была идея, что в лженериках был бы полезен thistype: http://blogs.byte-force.com/xor/archive/2009/09/15/thistype-for-generics.aspx
А>У меня еще была идея, что в лженериках был бы полезен thistype: http://blogs.byte-force.com/xor/archive/2009/09/15/thistype-for-generics.aspx
О, хорошее слово «лженерики». «Лженерики» — это дженерики в Джаве.
Q>Здравствуйте, Аноним, Вы писали:
А>>У меня еще была идея, что в лженериках был бы полезен thistype: http://blogs.byte-force.com/xor/archive/2009/09/15/thistype-for-generics.aspx
Q>О, хорошее слово «лженерики». «Лженерики» — это дженерики в Джаве.
На планшете вечно мимо кнопок промахиваюсь. Иногда — удачно.
AVK>Небольшое вступление.
AVK>Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing, т.е. основной фичи, вокруг которой строится весь релиз (типа linq в 3 версии, динамиков в 4 и асинка в 5). Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь.
AVK>Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
Последнее, что я слышал — все по уши застряли в Рослине, сильно сомневаюсь, что у них хватит сил на что-то ещё. Из мелочей в голову приходит только вот это:
1. По аналогии с [CallerMemberName] и прочими — [ArgExpression]: текст выражения в заданном атрибуте:
2. Явный duck typing, что то вида
Для скриптов (раз уж у нас шарп в ближайшем будущем можно будет хостить) можно дополнить анонимные типы до того, что есть в яве и добавить возможность передавать анонимные типы шарпа за границы метода (пускай и только для internal/protected-методов).
Но, опять-таки, если рослин допилят, такие мелочи можно будет сделать и самому, благо возможностей выше крыши. Code rewrite, AOP, рефакторинг, code analysis, script hosting — имхо, вполне тянет на big thing.
Ещё, судя по полунамёкам Липперта (сейчас не найду, но было ещё в паре статей), compiler team периодически думает над добавлением явного маппинга "ключевое слово — вызов подходящего метода", как это сделано для linq/foreach/await. Выглядит интересно, но насколько оно будет полезно на практике —
S>Последнее, что я слышал — все по уши застряли в Рослине, сильно сомневаюсь, что у них хватит сил на что-то ещё
Я не могу озвучивать конкретики, но ситуация несколько иная сейчас.
S>>Последнее, что я слышал — все по уши застряли в Рослине, сильно сомневаюсь, что у них хватит сил на что-то ещё
AVK>Я не могу озвучивать конкретики, но ситуация несколько иная сейчас.
Ок, значит отстал от жизни. Удачи им
AVK>Благодаря этому появилась возможность реализовать кучу мелких вещей, которые, с одной стороны, не требуют революций в языке их их можно реализовать сравнительно разумным объемом ресурсов, а с другой способны сильно облегчить жизнь.
AVK>Поэтому у меня есть желание сформировать некий документ со списком фич и отдать его дизайнерам шарпа. Гарантии, что хоть что то из него будет реализовано нет никакой, но шансы этого высоки как никогда
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее. Идеально было бы привести гипотетический пример исходного кода с описанием его семантики, и потом примерный код на текущем шарпе, в который первый пример должен раскрываться.
Хочу какой-нибудь синтаксический сахар для let/where: http://bik-top.livejournal.com/50984.html
AVK>Проголосовать за конкретные фичи можно здесь.
— Вывод типов при вызове констркуторов.
— nameof/infoof и т.п.
— приделать к query comprehensions to list, to array, first, single, top, skip и т.п.
— ПМ и АТД.
IT>- Вывод типов при вызове констркуторов.
+100
IT>- ПМ и АТД.
дико извиняюсь, что такое "ПМ" и что такое "АТД"?
по всей видимости, паттерн матчинг и алгебраические типы данных.
K>дико извиняюсь, что такое "ПМ" и что такое "АТД"?
Агебраические типы данных (ака Варианты или ограниченные объеденения) и сопоставление по ним.
http://nemerle.org/wiki/Grok_Variants_and_matching
IT>- Вывод типов при вызове констркуторов.
IT>- приделать к query comprehensions to list, to array, first, single, top, skip и т.п.
+1
IT>- nameof/infoof и т.п.
IT>- ПМ и АТД.
Ну у вас и мелочи
IT>>- ПМ и АТД.
G>Ну у вас и мелочи
На самом деле если разобраться, то и то и другое — это сахар. АТД — это плоская иерархия, по типу Linq.Expressions только с информацией о соответствии полей/свойст класса с их позиционированием в паттернах для ПМ. Немерле, кстати, умеет задавать такую информацию в том числе и для обычных классов. ПМ — это всего лишь навороченный switch/if с максимально компактным синтаксисом, включающим распаковку структур данных, и умным алгоритмом оптимизации перебора условий.
Единственное чем ПМ может не вписаться в C# — так это то, что в том же Немерле всё есть выражение и все языковые конструкции могут возвращать значение.
IT>- ПМ и АТД.
Основная проблема с ПМ, как озвучил Мэдс, в АТД. Это новый first class citizen, который отчасти дублирует существующие сущности в языке. Так что АТД ака discriminated unions на данный момент однозначно no way. Теоретически можно обойтись без АТД существующими типами с какими то дополнительными доработками, но тут нужно говорить более конкретно.
IT>>- ПМ и АТД.
AVK>Основная проблема с ПМ, как озвучил Мэдс, в АТД. Это новый first class citizen, который отчасти дублирует существующие сущности в языке.
И чего оно такого дублирует?
IT>И чего оно такого дублирует?
Обычные классы с виртуальными методами.
AVK>Здравствуйте, IT, Вы писали:
IT>>И чего оно такого дублирует?
AVK>Обычные классы с виртуальными методами.
А какая проблема в дублировании? В F# и Nemerle есть и обычные классы и АлгТД
S>А какая проблема в дублировании? В F# и Nemerle есть и обычные классы и АлгТД
Это не объектно-ориентированно! Вот то ли дело энумы в Яве?!
Хомечкам порвет мозг от возможности сделать что-то двумя путями. Пусть лучше паттернами проектирования пользуются и is/as-ами. А то не дай бок прострелят себе ногу не в том мести, а МС отвечать за это.
IT>>И чего оно такого дублирует?
AVK>Обычные классы с виртуальными методами.
Так можно договориться до того, что любой класс дублирует функциональность object.
IT>>И чего оно такого дублирует?
AVK>Обычные классы с виртуальными методами.
А чё ж с виртуальными то? Без них было бы проще?
А is/as их не дублирует? А то я тут много кода видел с is/as вместо "обычных виртуальных методов".
Об остальном я уже рядом написал.
AVK>Основная проблема с ПМ, как озвучил Мэдс, в АТД. Это новый first class citizen, который отчасти дублирует существующие сущности в языке. Так что АТД ака discriminated unions на данный момент однозначно no way. Теоретически можно обойтись без АТД существующими типами с какими то дополнительными доработками, но тут нужно говорить более конкретно.
Перевожу на русский язык — "Нам хочется еще лет 5-10 по-вредничать.", потому как в ином случае объяснить подобные утверждения можно только недостатком знаний и не желанием смотреть на то что валяется под ногами.
Начнем с того, что ПМ не имеет никакого отношения к АлгТД (АлгТД потому как АТД принято расшифровывать как Абстрактный Тип Данных, что из другой оперы).
Две основные фичи ПМ, которые делают его мощной штукой это:
1. Рекурсивность.
2. Динамические проверки типов.
Вот пример ПМ по классам из N2:
Здесь BaseRule и ExtentionType — это поля имеющие вариантный тип (АлгТД), а все остальное — это классы.
RuleSymbol — это свойство типа RuleDefSymbol, а ExtensibleRuleSymbol, ExtentionRuleSymbol, SimpleRuleSymbol и RegularRuleSymbol его наследники. Причем непрямые.
Мы используем классы для символов, так как нам нужна расширяемость, а вариантные типы этого не обеспечивают.
Кстати, закрытость набора можно обеспечить банальным seled.
Есть только одна фича МП которая упирается в возможности АлгТД — описание паттерна в виде конструктора. Это позволяет несколько сократить синтаксис описывая состояние объекта в виде параметров его конструктора. Чтобы это было возможно нужно иметь соответствие между полями типа и параметрами конструктора.
Так вот, во-первых можно обходиться несколько более длинным синтаксисом в котором внутри паттерна явно указывается имя члена который нужно проверить. Зачастую это даже оказывается более удобным, так как позволяет не перечислять все параметры конструктора забивая большую часть вилдкардами (знаком _ в ФЯ).
Во-вторых, соответствие между аргументами конструктора и полями можно задать и способами отличными от тех что используются в АлгТД. Например, можно обратиться к опыту Скалы. В ней можно объявлять конструкторы прямо в синтаксисе объявления классов (синтаксис псевдошарпа):
Здесь firstField и secondField это одновременно и поля класса С и параметры его единственного конструктора. Прибавляем сюда наследование и получаем все что нужно для классических конструкторных паттернов. Для старых типов можно использовать аннотацию задаваемую кастом-атрибутами.
В общем, если у них проблемы с дизайном, могу за скромную сумму (ну, скажем 10К зеленых) спроектировать поддержку ПМ для шарпа, что называется под ключ (с грамматикой и описанием семантики).
VD>В общем, если у них проблемы с дизайном, могу за скромную сумму (ну, скажем 10К зеленых) спроектировать поддержку ПМ для шарпа, что называется под ключ (с грамматикой и описанием семантики).
Могу за 20K в аналогичной валюте сделать ревью дизайна Влада. Если оно окажется типа "Всё OK", то всё равно бабки вперёд.
IT>Могу за 20K в аналогичной валюте сделать ревью дизайна Влада. Если оно окажется типа "Всё OK", то всё равно бабки вперёд.
Я не против. Все равно по сравнению с их затратами это демпинговые цены. Они же фичу рожают по два года и коллективно.
IT>>Могу за 20K в аналогичной валюте сделать ревью дизайна Влада. Если оно окажется типа "Всё OK", то всё равно бабки вперёд.
VD>Я не против. Все равно по сравнению с их затратами это демпинговые цены. Они же фичу рожают по два года и коллективно.
Работая в продуктовой конторе, могу вас, пацаны, разочаровать. В нужную работу, помимо проектирования и review, входит также мейнтенанс на пять лет вперёд (т.е. участие в дизайне всех будущих фич с учётом наличия этой существующей) и саппорт на десять лет вперёд (то есть помощь несчастным хомячкам, выстрелившим себе в ногу при помощи вашей фичи).
Стоимостью реализации при таких раскладах можно смело пренебречь. А запрошенные вами 30к на двоих эти две активности сожрут уже к концу 2014. Дальше вы будете работать себе в убыток.
А если вы откажетесь от этих "обременений" — то Редмонд ваше предложение никак не заинтересует. У них и своих проектировщиков хватает; с учётом ихних зарплат, проект+ревью им обойдётся тыщи в четыре, от силы в пять.
S>Работая в продуктовой конторе, могу вас, пацаны, разочаровать. В нужную работу, помимо проектирования и review, входит также мейнтенанс на пять лет вперёд
Ты видимо кем-то не тем работаешь. Любой работник отдела кадров и директор знает, что есть разные специалисты отвечающие за разные задачи. По идее не нужно быть курицей чтобы понимать толк в яичнице, но чем черт не шутит?
S>А если вы откажетесь от этих "обременений" — то Редмонд ваше предложение никак не заинтересует. У них и своих проектировщиков хватает; с учётом ихних зарплат, проект+ревью им обойдётся тыщи в четыре, от силы в пять.
Убедил. Я отказываюсь от своего предложения.
существующей) и саппорт на десять лет вперёд (то есть помощь несчастным хомячкам, выстрелившим себе в ногу при помощи вашей фичи).
S>Стоимостью реализации при таких раскладах можно смело пренебречь. А запрошенные вами 30к на двоих эти две активности сожрут уже к концу 2014. Дальше вы будете работать себе в убыток.
Скорее к концу 2013.
если из мелких фич, то
1) сплайс строк
2) чуть по продвинутей вывод дженерик аргументов
А если покупнее, то ПМ
А, и еще не знаю насколько это "крупно", но очень хочется возможность комбинирования expression-trees
если не ошибаюсь в F# есть такая фича.
— extension метод .ForEach для IEnumerable
— просто ради красоты — возможность писать код без ";" в конце каждой строчки : )
и, как уже указал "IT" в http://www.rsdn.ru/forum/dotnet/5074746.1
— Вывод типов при вызове констркуторов
K> — просто ради красоты — возможность писать код без ";" в конце каждой строчки : )
Тогда придется спилить безымянный палец. Чтоб не стучал по клавише ;
M>Здравствуйте, k0st1x, Вы писали:
K>> — просто ради красоты — возможность писать код без ";" в конце каждой строчки : )
M>Тогда придется спилить безымянный палец. Чтоб не стучал по клавише ;
как временное решение или workaround,
можно примотать мизинец к безымянному пальцу, ну или приклееть суперклеем.
M>>Тогда придется спилить безымянный палец. Чтоб не стучал по клавише ;
K>как временное решение или workaround,
K>можно примотать мизинец к безымянному пальцу, ну или приклееть суперклеем.
Я использовал более радикальный вариант: ездил на велосипеде по городу без гарда на руле. В итоге на три недели мизинец пригипсовали к безымянному.
K>как временное решение или workaround,
K>можно примотать мизинец к безымянному пальцу, ну или приклееть суперклеем.
Пиши на VB
Сё>Здравствуйте, k0st1x, Вы писали:
K>>как временное решение или workaround,
K>>можно примотать мизинец к безымянному пальцу, ну или приклееть суперклеем.
Сё>Пиши на VB
прискорбно, что смена языка — единственное решение неудобства
AVK>те фичи, которых не хватает лично вам.
вместо
Это кажется называется Maybe monad.
Синтаксис подсмотрен у Bart de Smet.
AK>Здравствуйте, AndrewVK, Вы писали:
AVK>>те фичи, которых не хватает лично вам.
AK>
AK>вместо
AK>
AK>Это кажется называется Maybe monad.
AK>Синтаксис подсмотрен у Bart de Smet.
Туда же NotNull ссылки. Но это уже CLR -(
J>Туда же NotNull ссылки.
Боюсь, для этого нужно написать CLR с нуля
AK>
AK>Это кажется называется Maybe monad.
AK>Синтаксис подсмотрен у Bart de Smet.
а если бы дальше первого fail-by-null не выходило, цены бы ему не было
в groovy такое было реализовано, имхо люто неудобно.
K>было бы здорово иметь возможность писать
K>
Уже существующим синтаксисом не обойтись, нужно новый придумывать, иначе такая фича поломает обратную совместимость.
J>Здравствуйте, k0st1x, Вы писали:
K>>было бы здорово иметь возможность писать
K>>
J>Уже существующим синтаксисом не обойтись, нужно новый придумывать, иначе такая фича поломает обратную совместимость.
вообще, идею увидел в проекте Kotlin.
jetbrains как-то живет с такой фичей
K>Здравствуйте, Jack128, Вы писали:
J>>Здравствуйте, k0st1x, Вы писали:
K>>>было бы здорово иметь возможность писать
K>>>
J>>Уже существующим синтаксисом не обойтись, нужно новый придумывать, иначе такая фича поломает обратную совместимость.
K>вообще, идею увидел в проекте Kotlin.
K>jetbrains как-то живет с такой фичей
кстати, здесь описание этой фичи
до этой минуты даже не догадывался, что это называется "Pattern matching" )
K>вообще, идею увидел в проекте Kotlin.
K>jetbrains как-то живет с такой фичей
У Kotlin проблема обратной совместимости ещё не стоит, и до первого официального релиза можно синтаксисом крутить и вертеть как угодно.
K>вообще, идею увидел в проекте Kotlin.
K>jetbrains как-то живет с такой фичей
Там язык с нуля проектировался и другого поведения нет. Кроме того там оно не для всех случаев работает, вроде как. Потому как для изменяемых переменных поведение будет кривым.
J>Здравствуйте, k0st1x, Вы писали:
K>>было бы здорово иметь возможность писать
K>>
J>Уже существующим синтаксисом не обойтись, нужно новый придумывать, иначе такая фича поломает обратную совместимость.
я тут подумал и не смог придумать, какой сценарий поломает обратную совместимость?
J>>Уже существующим синтаксисом не обойтись, нужно новый придумывать, иначе такая фича поломает обратную совместимость.
K>я тут подумал и не смог придумать, какой сценарий поломает обратную совместимость?
а тебе придумывать не нужно, я уже придумал. И даже написал этот пример, но ты при цитировании почему то удалил его.
J>а тебе придумывать не нужно, я уже придумал. И даже написал этот пример, но ты при цитировании почему то удалил его.
В принципе это решаемо эвристиками в компиляторе. Так что если очень хочется, то можно.
J>Здравствуйте, k0st1x, Вы писали:
J>>>Уже существующим синтаксисом не обойтись, нужно новый придумывать, иначе такая фича поломает обратную совместимость.
K>>я тут подумал и не смог придумать, какой сценарий поломает обратную совместимость?
J>а тебе придумывать не нужно, я уже придумал. И даже написал этот пример, но ты при цитировании почему то удалил его.
извиняюсь, действительно упустил.
btw, проверил этот сценарий в котлине — он ругается и не дает скомпилить.
K>извиняюсь, действительно упустил.
K>btw, проверил этот сценарий в котлине — он ругается и не дает скомпилить.
В котлике есть неизменяемые локальные переменные. Для них этот прокатывает. Хотя, все равно дизайн спорный выходит. В немерле можно использовать стандартный ПМ:
"y" имеет тип "Y" и является неизменяемой переменной. В "x" по прежнему можно присваивать новое значение (если она изменяемая) и тип у него прежний.
еще вот на ходу вспоминаю, чего не хватает
— default value для auto property
: )
1. Not null ссылки, желательно по умолчанию.
2. Алгебраические типы данных.
3. Паттерн-матчинг — в том числе по обычным типам.
Например, так:
Порядок значения не имеет, что вспомнилось.
Уточнение типа не хватает. Сейчас:
С уточнением типов:
Как уже скзали, расширение query для возможности естественного вызова Aggregate/Skip/etc (например как в VB) + поддержка пользовательских расширений.
Например сейчас:
Хотелось бы:
Тип переменной "х" — это тип выражения после "as". Так же получится удобное использование First[OrDefault] и т.п. если не придумают, как эти методы более естественно внедрить в query.
Так же реквестую nameof/infoof и "ПМ и АТД"
Синтаксис для простого написания имутабельных типов и билдеров к ним, если эту задачу нельзя не будет решить с появлением Розлина.
Лямбда и моджификаторы параметра (ref/out)
Полная поддержка компилятором Expression, в ветвлениями и прочим. Поддержка в выражениях подстановок. Хотя бы так:
using-директива c открытыми дженерик-типами:
а так же using-директива внутри класса (для использования там объявленных в классе дженерик-типов).
Контракты на декларативном уровне а-ля Spec# http://research.microsoft.com/en-us/projects/specsharp/
_FR>Порядок значения не имеет, что вспомнилось.
Да, за оператор .? тоже громко реквестую.
Хотелось бы иметь ограничение дженериков как простых типов, чтобы можно было реализовывать быстрые вычисления.
Что-то вроде:
Но это нужна доработка CLR.
K>Хотелось бы иметь ограничение дженериков как простых типов, чтобы можно было реализовывать быстрые вычисления.
Это уже несколько лет как одна из самых востребованных фич к рантайму, и про это команде CLR известно, но пока ничего конкретного нет.
K>Хотелось бы иметь ограничение дженериков как простых типов, чтобы можно было реализовывать быстрые вычисления.
В эту же кучу ограничение дженериков на параметризованный конструктор типа.
--
С Уважением, Andir!
A>Здравствуйте, koodeer, Вы писали:
K>>Хотелось бы иметь ограничение дженериков как простых типов, чтобы можно было реализовывать быстрые вычисления.
A>В эту же кучу ограничение дженериков на параметризованный конструктор типа.
A>--
A>С Уважением, Andir!
Вот это точно! А ещё ограничение на отсутсвие управляемых указателей, чтоб можно было писать
А самое желательное, то что вообще-то есть, но не в пользовательской версии, а в Singularity — восклицательные знаки для запрета пустых указателей.
1. АТД и ПМ
2. Довести поддержку локальных функций до уровня Немерле
3. Туплы, встроенные в язык
A>Мнение ламера. Как мейнстримовый язык шарп почти идеален, Roslyn видимо позволит фишек по части синтаксиса добавить. А вот по части кроссплатформенности\оперсорса джавe проигрывает конечно. На много серверов винду не поставишь увы, и под себя не перепишешь то, что не особенно нравится\баг пофиксить быстро. И имхо, для этого нужно более активное участие самой Microsoft. За код спасибо, но WPF, например, могли сделать не на directx, а на том же opengl, и всё стало бы чуть проще по части GUI. Ну и вообще какой-то бред, когда в Mono приходится переписывать то, что уже написано в MS.
А что мешает моно на сервер поставить?
А по теме: ПМ, АТД, кортежи, встроенные в язык и индексаторы в foreach.
A>А что мешает моно на сервер поставить?
Мешает то, что банальнейшая прога на winforms .net4.0 c mysql коннектором (который специально под mono) на убунте с 2.10.8.1 вылетает при запуске с замечательной ошибкой " Could not load file or assembly 'MySql.Data, Version=6.5.5.0, ...", которая валяется в той же папке. И какая тут "Yes, Mono is binary compatible with Windows."? Не тянет писать под Mono с его приколами, а не под .net как единую платформу аля java. В принципе всё решаемо, опять-таки java либы через ikvm можно на крайний случай для кроссплатформенности использовать. MS мог бы выпустить CLR под линукс, мб и с покоцанным функционалом типа wpf, хоть серваки гонять, но чтобы работало всё так же как на винде.
A>Здравствуйте, Aлeкceй, Вы писали:
A>>А что мешает моно на сервер поставить?
A>Мешает то, что банальнейшая прога на winforms .net4.0 c mysql коннектором (который специально под mono) на убунте с 2.10.8.1 вылетает при запуске с замечательной ошибкой " Could not load file or assembly 'MySql.Data, Version=6.5.5.0, ...", которая валяется в той же папке. И какая тут "Yes, Mono is binary compatible with Windows."? Не тянет писать под Mono с его приколами, а не под .net как единую платформу аля java. В принципе всё решаемо, опять-таки java либы через ikvm можно на крайний случай для кроссплатформенности использовать. MS мог бы выпустить CLR под линукс, мб и с покоцанным функционалом типа wpf, хоть серваки гонять, но чтобы работало всё так же как на винде.
Зачем Майкрософту рубить сук, на котором он сидит?
Компания зарабатывает деньги не на продаже .NET, а на продаже операционной системы Windows. .NET — это средство для облегчения создания программ под Windows сторонним производителям, а не способ облегчить перенос этих программ на другие платформы.
Именно поэтому компания поддерживает платформу Mono ровно настолько, чтобы её не обвинили в монополизме, и ни на грамм больше.
A>Зачем Майкрософту рубить сук, на котором он сидит?
A>Компания зарабатывает деньги не на продаже .NET, а на продаже операционной системы Windows. .NET — это средство для облегчения создания программ под Windows сторонним производителям, а не способ облегчить перенос этих программ на другие платформы.
A>Именно поэтому компания поддерживает платформу Mono ровно настолько, чтобы её не обвинили в монополизме, и ни на грамм больше.
Спасибо кэп, открыли глаза Момент в том, что dotnet и C# как пророк его возможно мог бы продаваться "лучше" винды. Как отдельный продукт. Ну естественно по другим ценам, но по 10 баксов за лицензию бессрочную на систему можно было бы за него платить. Ну а с виндой вроде как бесплатно бы шёл. Как это сделать вопрос второй. В принципе да, особых надежд не питаю. Если бы было бесплатно, то это скорее уже была бы java с её недостатками из-за отсутствия централизации.
A>Момент в том, что dotnet и C# как пророк его возможно мог бы продаваться "лучше" винды.
На фоне бесплатной джавы?
AVK>Здравствуйте, agat50, Вы писали:
A>>Момент в том, что dotnet и C# как пророк его возможно мог бы продаваться "лучше" винды.
AVK>На фоне бесплатной джавы?
Ну винда же продаётся на фоне бесплатной убунты. Мне, например, шарп нравится весьма как язык, почему бы и не платить. Естественно, если это будет удобно осуществимо.
AVK>Здравствуйте, agat50, Вы писали:
A>>Момент в том, что dotnet и C# как пророк его возможно мог бы продаваться "лучше" винды.
AVK>На фоне бесплатной джавы?
Ксамарин для Андроида продается на фоне бесплатной явы.
A>Здравствуйте, alexanderfedin, Вы писали:
A>>Зачем Майкрософту рубить сук, на котором он сидит?
A>>Компания зарабатывает деньги не на продаже .NET, а на продаже операционной системы Windows. .NET — это средство для облегчения создания программ под Windows сторонним производителям, а не способ облегчить перенос этих программ на другие платформы.
A>>Именно поэтому компания поддерживает платформу Mono ровно настолько, чтобы её не обвинили в монополизме, и ни на грамм больше.
A>Спасибо кэп, открыли глаза Момент в том, что dotnet и C# как пророк его возможно мог бы продаваться "лучше" винды. Как отдельный продукт. Ну естественно по другим ценам, но по 10 баксов за лицензию бессрочную на систему можно было бы за него платить. Ну а с виндой вроде как бесплатно бы шёл. Как это сделать вопрос второй. В принципе да, особых надежд не питаю. Если бы было бесплатно, то это скорее уже была бы java с её недостатками из-за отсутствия централизации.
Видимо, открыл не до конца
Windows & Office — это две cash cows компании. Наибольший доход от их продажи компания получает не из розничных продаж, а от всяких DELL/HP/ACER/etc., которые предустанавливают этих дойных коров на продаваемые компы.
Отношение количества девелоперов в мире к количеству остальных юзеров, я думаю, даже не в сотни раз. Поэтому предустанавливать Visual Studio или даже .NET SDK на все компы смысла ноль — затраты не отобъёшь.
Если компания сделает средство разработки многоплатформенным среди не своих платформ, то тем самым она своими собственными руками выпилит сук, на которых сидит — заложит основу для перевода пользователей на нругие платформы. И вот представьте: за средство разработки денег больших не поднять, а платформа больше не приносит того огромного бабла. А виноват в этом тот, кто решил "дать людЯм свободу, равенство и братство" в выборе платформы для разработки.
A>Здравствуйте, agat50, Вы писали:
A>>Здравствуйте, alexanderfedin, Вы писали:
A>>>Зачем Майкрософту рубить сук, на котором он сидит?
A>>>Компания зарабатывает деньги не на продаже .NET, а на продаже операционной системы Windows. .NET — это средство для облегчения создания программ под Windows сторонним производителям, а не способ облегчить перенос этих программ на другие платформы.
A>>>Именно поэтому компания поддерживает платформу Mono ровно настолько, чтобы её не обвинили в монополизме, и ни на грамм больше.
A>>Спасибо кэп, открыли глаза Момент в том, что dotnet и C# как пророк его возможно мог бы продаваться "лучше" винды. Как отдельный продукт. Ну естественно по другим ценам, но по 10 баксов за лицензию бессрочную на систему можно было бы за него платить. Ну а с виндой вроде как бесплатно бы шёл. Как это сделать вопрос второй. В принципе да, особых надежд не питаю. Если бы было бесплатно, то это скорее уже была бы java с её недостатками из-за отсутствия централизации.
A>Видимо, открыл не до конца
A>Windows & Office — это две cash cows компании. Наибольший доход от их продажи компания получает не из розничных продаж, а от всяких DELL/HP/ACER/etc., которые предустанавливают этих дойных коров на продаваемые компы.
A>Отношение количества девелоперов в мире к количеству остальных юзеров, я думаю, даже не в сотни раз. Поэтому предустанавливать Visual Studio или даже .NET SDK на все компы смысла ноль — затраты не отобъёшь.
A>Если компания сделает средство разработки многоплатформенным среди не своих платформ, то тем самым она своими собственными руками выпилит сук, на которых сидит — заложит основу для перевода пользователей на нругие платформы. И вот представьте: за средство разработки денег больших не поднять, а платформа больше не приносит того огромного бабла. А виноват в этом тот, кто решил "дать людЯм свободу, равенство и братство" в выборе платформы для разработки.
Намёк понятен?
Причём тут средство разработки, я не предлагаю сделать студию портируемой, только CLR с классами. Как и sql server, axapta, directx и т.п. Пусть они останутся привязаны к винде, нет вопросов. Но имхо dotnet весьма страдает как серверная платформа из-за ограничений этих, ну не могу я на 5 виртуалок винду лицензии поставить. Не говоря про отсутствие лёгких дистрибутивов винды типа ubuntu server. Вообще забейте, надо будет, с моно разберусь конечно.
A>Если компания сделает средство разработки многоплатформенным среди не своих платформ, то тем самым она своими собственными руками выпилит сук, на которых сидит
Не совсем всё так однозначно. Сейчас вот что мы имеем? Сидит какой-нть прыщавый виндо-хэйтер и решает — и винда вроде нужна, и сишарпить под ней можно, но внутренний
кретинголос говорит — "а мы уйдём на север!". Причём полностью уйдём — на линупс+пестон, например. И получается, что вместо придержания "многоплатформенного" хэйтера, который мог бы делать софт ДЛЯ ОБЕИХ платформ, мелкософт ПОЛНОСТЬЮ теряет отдельного специалиста!Когда выбор "или-или" — теряют все. Просто дебилам в руководстве проще изображать из себя властелина платформы, чем думать мозгами и грести бабло экскаваторами. А с планшетно-мобильной волной вообще вымывает все стойки под виндоофисом: если раньше выбор был "мак или вынь" (причём сильно в пользу последней), то сейчас уже задумываются "а нужен ли мне десктопный виндовоз вообще?".
Я думаю, что это могло бы быть С# 1.0, но до сих пор почему-то нет...
А>Сделайте union наконец (хотя бы для ссылочных типов)
А>Я думаю, что это могло бы быть С# 1.0, но до сих пор почему-то нет...
Зачем?
А>Сделайте union наконец (хотя бы для ссылочных типов)
А>Я думаю, что это могло бы быть С# 1.0, но до сих пор почему-то нет...
FieldOffsetAttribute доступен с первого фреймворка.
Z>FieldOffsetAttribute доступен с первого фреймворка.
Попробуй, ради хохмы, таким образом совместить ссылочный тип и какой-нибудь long. Узнаешь много нового.
VD>Попробуй, ради хохмы, таким образом совместить ссылочный тип и какой-нибудь long. Узнаешь много нового.
А какой в этом смысл в мире управляемых указателей?
VD>>Попробуй, ради хохмы, таким образом совместить ссылочный тип и какой-нибудь long. Узнаешь много нового.
Z>А какой в этом смысл в мире управляемых указателей?
Смысл может быть любой. Он задачей определяется. Это же просто объединение двух величин. Например, строки и целого. А вот работать не будет, так как CLR не позволяет совместить указатель и значение. GC тупо упадет.
VD>А вот работать не будет, так как CLR не позволяет совместить указатель и значение. GC тупо упадет.
Указатель и значение CLR позволяет "совместить". Не допускается перекрытие типов-ссылок с типами-значениями.
VD>Смысл может быть любой. Он задачей определяется. Это же просто объединение двух величин. Например, строки и целого. А вот работать не будет, так как CLR не позволяет совместить указатель и значение. GC тупо упадет.
Ты про то, что GC следит за всеми указателями и падает если испортить один из них? Есть такая проблема, да, нельзя смешать value и cсылку. Два значения смешать нет проблем, а две ссылки смешивать нет смысла (можно просто хранить один object).
Z>Ты про то, что GC следит за всеми указателями и падает если испортить один из них? Есть такая проблема, да, нельзя смешать value и cсылку. Два значения смешать нет проблем, а две ссылки смешивать нет смысла (можно просто хранить один object).
Такая проблема есть в реализации .НЕТного ГЦ, а не ГЦ вообще.
Ибо ни что не мешает сделать ГЦ, который понимает, в каком состоянии находится объединение.
AVK>Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing
Их не было и в 5 релизе — ну не async же — революция программазма!
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
Забавно — т.е. к народу обращаются только когда ИМ нужно? Я думал, MS просто завален предложениями на десятилетие вперёд! И предложения совсем не обязательно должны быть big thing — даже элементарные вещи могут делать жизнь прогера намного легче. Ладно, раз уж дали высказаться, нате вам:
Авто-инициализация авто-проперти:
Это мелочи, но без них ШАРП БЕСИТ!Автопроперть тоже сократить до: prop int a; // паблик проперть для r/w; куча приложений идёт именно с таким дефолтом, почему б его не сократить? Заодно ускорится компиляция.
Мультиприсвоение: var (a, b) = GetCoords(); // в a и b попадают отдельные числа. Т.е. типа кортежа, но без кортежа. Перл это умеет на раз-два. Сишарп ждём уже 10 лет....
Ещё один вид мультистрочных каментов (а-ля D): /+ это отладочный коммент /* скрывающий рабочий коммент */ и нужный только временно +/
Раз уж строки являются "немного встроенным" и широко используемым типом, нельзя ли упростить дебилизм типа if (!string.IsNullOrWhiteSpace(бла-бла...)) на что-то типа if (^string_var) — это сократило бы целую кучу кода.
Вывод типов для филдов: var SomeField = 6; // знаю, есть проблемы, но они трясут в 0.000001% случаев — так не лучше ли сделать жизнь большинства легче?!
Если тип переменной уже известен, пересоздавать её простым способом: — бенефит очевиден при использовании всяких трёхэтажных генериков.
.ToString() бесит. Можно как в Руби: obj.ToS ? (заметьте — без скобок)
Синонимы функций. Console.WriteLine задолбал — хочу типа так:
Зачем в switch(SomeEnumVar) пишут в case SomeDamnBigEnumName.EnumValue: ? нельзя ли просто switch(SomeEnumVar) case EnumValue: — тип-то везде один и тот же!
Приведение типов неуклюжее. Вместо можно было б писать , т.е. := — это "присвоить с приведением типа к lvalue". Словесный понос надо искоренять — пусть паскалисты его тыркают.
Фичи из голосовалки, к которым +100:
Сиськи!
Expression Substitution вместо string.Format
Синтаксис для кортежей с поддержкой везде: foreach(var (x, y) in seq)
Хочется, чтобы офигевшие от своей крутости шарподелы спустились на землю и не выпежонивались "суперфичами", а слушали тех, кто РЕАЛЬНО использует шарп — это МЫ ежедневно колдыбасимся с их компилером и это нам виднее, что есть "мелочи". А если ради мелочей надо переписывать компилер, то.... в топку такие компилеры.
M>*Раз уж строки являются "немного встроенным" и широко используемым типом, нельзя ли упростить дебилизм типа if (!string.IsNullOrWhiteSpace(бла-бла...)) на что-то типа if (^string_var) — это сократило бы целую кучу кода.
ну сделай экстеншн метод if (string_var.A) и кол-ву символов, и по читабельности примерно одинаково.
M>*Приведение типов неуклюжее. Вместо можно было б писать , т.е. := — это "присвоить с приведением типа к lvalue". Словесный понос надо искоренять — пусть паскалисты его тыркают.
чем те var z = (double)IntVar не устраивает?
J>чем те var z = (double)IntVar не устраивает?
Тем, что это абсолютно левый пример. Я хочу избавиться от _приведения_типа_, а не замены double на var.
M>Здравствуйте, Jack128, Вы писали:
J>>чем те var z = (double)IntVar не устраивает?
M>Я хочу избавиться от _приведения_типа_, а не замены double на var.
нет, ты предлагаешь заменить один синтаксис приведения другим.
AVK>>Сейчас сложилась такая ситуация, что для следующего релиза C# нет big thing
M>Их не было и в 5 релизе — ну не async же — революция программазма!
Под революциями я имел в виду масштабные изменения конкретно в C#, а не новые открытия в computer science.
AVK>>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
M>Забавно — т.е. к народу обращаются только когда ИМ нужно?
Здесь к народу обращаюсь я, и я в МС не работаю, не переживай.
M>Хочется, чтобы офигевшие от своей крутости шарподелы спустились на землю и не выпежонивались "суперфичами", а слушали тех, кто РЕАЛЬНО использует шарп — это МЫ ежедневно колдыбасимся с их компилером и это нам виднее, что есть "мелочи". А если ради мелочей надо переписывать компилер, то.... в топку такие компилеры.
Ты продолжай в таком тоне общаться, и тебя вообще никто слушать не будет.
AVK>Ты продолжай в таком тоне общаться, и тебя вообще никто слушать не будет.
Извиняюсь, поторопился. Как в анеке: "Да пошла она со своей солью!". Просто язык как был низкоуровневой "си-подобной" фигнёй, так за 10 лет и не вырос. И главное, разрабы думают о каких-то "киллер-фичах", хотя у языка хватает и "обычных" улучшений — посмотри сколько в ветке собралось "мелочей". Уверен, никто их даже читать не будет — они, видите ли, не подходят для маркетоидных испражнений. Вот так яснее моё негодование?
M>Уверен, никто их даже читать не будет
Ты не прав. Я вчера утром про этот топик рассказал Мэдсу, и позже он говорил, что ждет когда я скомпилирую суммарный документ.
AVK>Ты не прав. Я вчера утром про этот топик рассказал Мэдсу, и позже он говорил, что ждет когда я скомпилирую суммарный документ.
Вообще есть шанс, что хоть какие-нибудь наши хотелки реализуют?
A>Вообще есть шанс, что хоть какие-нибудь наши хотелки реализуют?
Шанс есть. А вот какой — этого я сказать не могу.
M>Приведение типов неуклюжее. Вместо можно было б писать , т.е. := — это "присвоить с приведением типа к lvalue". Словесный понос надо искоренять — пусть паскалисты его тыркают.
Я не понял, почему нельзя так написать?
Упрощённая работа с атрибутами. Какой смысл рассуждать об их пользе, если работа с ними осущ. через анус? Хочется изящной простоты, типа: foreach(PropInfo pi in WindowType.class.GetProperties(Attr1, attr2, ..)); Или PropInfo.HasAttribute(AttrClass); Вообще, у C# довольно помоечный синтаксис работы с классами: вместо элегантных конструкций с именами типов приходится влезать чуть ли не в ассемблер: Класс.ДайСвойТип().ШаманскиеФункции.... отстой полнейший. Нужен синтаксис сразу на уровне "Класс", типа "Класс.ДайПропертиСАтрибутом(Атрибут)". Это мелочи, но без них код загромождается фуфлом — хорошо бы девелоперам сишарпа заботиться не только "предоставить доступ к фиче", но и о элегантности кода с этими фичами.
Оператор .?
Улучшить оператор AS: нечасто, но изрядно упрощает бойлерплэйт a = b as SomeType; if (a != null) ....; Вариант: when(b = a as SomeType) { юзаем b }
Упрощ. иниц. объекта помимо new: var z = GetObject() <= { filed = 4, field2 = 5 }
Duck typing ака MapAs: приводить объект к интерфейсу, если он совместим по методам. Уж лучше в рантайме всё **нётся, зато в коде можно очень элегантно обруливать всякое гетерогенное фуфло из разных иерархий.
M>Пробежался по треду и собрал ещё фич, которые поддерживаю (почему-то в голосовалке — мусор вместо дельных пунктов):
M>Упрощённая работа с атрибутами. Какой смысл рассуждать об их пользе, если работа с ними осущ. через анус? Хочется изящной простоты, типа: foreach(PropInfo pi in WindowType.class.GetProperties(Attr1, attr2, ..)); Или PropInfo.HasAttribute(AttrClass);
При чём тут C#?
M>Вообще, у C# довольно помоечный синтаксис работы с классами: вместо элегантных конструкций с именами типов приходится влезать чуть ли не в ассемблер: Класс.ДайСвойТип().ШаманскиеФункции.... отстой полнейший. Нужен синтаксис сразу на уровне "Класс", типа "Класс.ДайПропертиСАтрибутом(Атрибут)". Это мелочи, но без них код загромождается фуфлом — хорошо бы девелоперам сишарпа заботиться не только "предоставить доступ к фиче", но и о элегантности кода с этими фичами.
M>Оператор .?
M>Улучшить оператор AS: нечасто, но изрядно упрощает бойлерплэйт a = b as SomeType; if (a != null) ....; Вариант: when(b = a as SomeType) { юзаем b }
M>Упрощ. иниц. объекта помимо new: var z = GetObject() <= { filed = 4, field2 = 5 }
Зачем?
M>Duck typing ака MapAs: приводить объект к интерфейсу, если он совместим по методам. Уж лучше в рантайме всё **нётся, зато в коде можно очень элегантно обруливать всякое гетерогенное фуфло из разных иерархий.
Реализовано в библиотеках — BLToolkit смотрели?
S>При чём тут C#?
Чуть ниже я объяснил причём:
M>>Вообще, у C# довольно помоечный синтаксис работы с классами: вместо элегантных конструкций с именами типов приходится влезать чуть ли не в ассемблер: Класс.ДайСвойТип().ШаманскиеФункции.... отстой полнейший. Нужен синтаксис сразу на уровне "Класс", типа "Класс.ДайПропертиСАтрибутом(Атрибут)".
Без поддержки языка это не делается в принципе.
Путь C# будет "чуть более бейсиком" — упрощать низкоуровневый код. Сей и Сипипей мы уже наелись, пора как-то подымать уровень!
M>>Улучшить оператор AS: нечасто, но изрядно упрощает бойлерплэйт a = b as SomeType; if (a != null) ....; Вариант: when(b = a as SomeType) { юзаем b }
S>a.WhenIs<SomeType>{b=>юзаем b }
Костыли не интересны ввиду своей неэлегантности. Тот же ?: тоже выражается через if'ы, тем не менее, его ввели в язык.
И потом, можно провести анализ кода — поискать наиболее употребимые конструкции и решить как их можно упростить.
M>>Упрощ. иниц. объекта помимо new: var z = GetObject() <= { filed = 4, field2 = 5 }
S>Зачем?
Можно не вводить, если реализуют паскалевский with.
Синклер, если следовать логике Смоллтока, можно вообще оставить две вещи — присвоение и посылка сообщения. Но люди почему-то хотят иметь более "читаемый" код.
M>>Duck typing ака MapAs: приводить объект к интерфейсу, если он совместим по методам.
S>Реализовано в библиотеках — BLToolkit смотрели?
эээ... Я БЛТ юзаю только для БД. Надо будет глянуть, пасип
M>Можно не вводить, если реализуют паскалевский with.
Паскалевский with скорее зло, чем благо. Особенно когда они вложены друг в друга.
Реально что в паскале удобнее, чем в c#:
1. это явное приведение типов не (Type)exp, а Type(exp)
2. очень не хватает множеств set и операций с ними в приятном синтаксисе, а не вызове методов класса.
А>Паскалевский with скорее зло, чем благо. Особенно когда они вложены друг в друга.
Как и в JavaScript, потому что к with нет явной привязки к контексту. В VB.NET, как я понимаю, привязка есть.
Оператор with
(именно с точкой перед именем метода или свойства, как в VB)
хотелось бы сразу после открытия файла видеть, какие public и protected методы в нём описаны.
AVK>skipped
Добавлю свои 5 копеек:
1) switch по всему, чему угодно, очень надоело писать костыли в виде словарей. Т.е., вместо, например, этого:
писать так:
Пусть это все разворачивается в тот же Dictionary, но типовым и однообразным способом.
2) [PropertyChanging] и [PropertyChanged] для автосвойств искаропки:
3) Разрешить инициализатору поля ссылаться на экземплярный метод, поле или свойство, сейчас вместо этого приходиться городить конструктор:
4) Разрешить использовать экземплярный метод, поле или свойство при вызове конструктора базового класса:
5) Разрешить использовать значения свойств объекта в инциализаторе этого же объекта. Вместо:
писать:
Если в текущем контексте уже есть MyIntProperty, разруливать неоднозначность в пользу уже существующего идентификатора, либо считать это ошибкой.
6) Убрать неоднозначность при явном задании размера массивов (для явно типизированных — можно, для неявно типизированных — почему-то нельзя, http://stackoverflow.com/questions/14597522/implicitly-typed-arrays-why-we-cant-set-array-size-explicitly).
Сецчас язык настолько опережает рантайм, что дальнейшие "мажорные" фичи — это рост колосса на глиняных ногах.
С точки зрения людей, не знакомых с кухней MS, C# и .NET CLR — даже не муж и жена, а вообще один человек.
Так что все силы надо пускать на CLR — многоплатформенность, нормальные оптимизации, наконец-таки нормальный x64, внятный и предсказуемый GC
А что не так с x64 если не секрет? Ну и чем GC не предсказуем?
Просто интересуюсь
Tom>А что не так с x64 если не секрет?
Полное отсутствие оптимизаций
Tom>Ну и чем GC не предсказуем?
Тут я не могу строго сформулировать... Но общее ощущение что он "живет своей жизнью", в отличии от jvm. Ну и захлебывается на гораздо меньших объемах кучи.
Что надо и хочется чтоб было сделано —
1) инкрементальная фоновая сборка в gen2 БЕЗ релокации до определенного % наполнения кучи
2) сборка в LOH с релокацией
3) раздельные (конфигурябельно) GEN0 кучи для тредов для устраниния эффекта "кризиса среднего возраста"
и т.д.
X>Здравствуйте, Tom, Вы писали:
Tom>>А что не так с x64 если не секрет?
X>Полное отсутствие оптимизаций
я не знаток во внутренних оптимизациях .net'а, но мне казалось, что TCO работает только в x64;
чем не оптимизация?
X> 2) сборка в LOH с релокацией
А в 4.5 разве это не появилось ?
Tom>А что не так с x64 если не секрет?
Он крайне дохлый в плане оптимизации. Поэтому первым будут заменять именно его.
AVK>Здравствуйте, Tom, Вы писали:
Tom>>А что не так с x64 если не секрет?
AVK>Он крайне дохлый в плане оптимизации. Поэтому первым будут заменять именно его.
попробовал выполнить код(ниже) на жаве и сишарп
2.9гг
c# — релиз, nf4.5(64 бита за 1700 млс, 32 — 2044)
java — jdk 7u15 выполняет за 2000 млс,
так что вроде с оптимизациями нормально или чтото не так под эклипсом запустил?
K>попробовал выполнить код(ниже) на жаве и сишарп
При чем тут джава? Ты 32 и 64 бита сравни, да не на синтетике, а на реальном коде.
X>Сецчас язык настолько опережает рантайм, что дальнейшие "мажорные" фичи — это рост колосса на глиняных ногах.
X>С точки зрения людей, не знакомых с кухней MS, C# и .NET CLR — даже не муж и жена, а вообще один человек.
X>Так что все силы надо пускать на CLR — многоплатформенность, нормальные оптимизации, наконец-таки нормальный x64, внятный и предсказуемый GC
Не согласен. Тот же Немерле опровергает эту теорию. Например, хвостовая рекурсия в нём работает давно, без поддержки CLR и гораздо более эффективнее. А дженерики, методы расширения, тюплы и аналог динамиков в нём появились раньше, чем это появилось в CLR.
X>Сецчас язык настолько опережает рантайм, что дальнейшие "мажорные" фичи — это рост колосса на глиняных ногах.
По рантайму тоже подвижки есть, кроме того, сейчас команда рантайма намного теснее работает с шарповской, нежели раньше. Но подробности пока под NDA.
X>Так что все силы надо пускать на CLR — многоплатформенность, нормальные оптимизации, наконец-таки нормальный x64, внятный и предсказуемый GC
Многоплатформенности ждать не стоит, остальное вполне.
X>Так что все силы надо пускать на CLR — многоплатформенность, нормальные оптимизации, наконец-таки нормальный x64, внятный и предсказуемый GC
Там команды разные. Так что силы перебросить не удастся.
К тому же 90% хотелок, описанных в этой теме, реализуются без изменения рантайма.
AVK>Небольшое вступление.
computation expressions, как в F#
http://msdn.microsoft.com/en-us/library/dd233182.aspx
Расширеная поддержка туплов, множественное присваивание:
Компайл тайм рефлексия:
Расширеная поддержка выражений:
Разворачивается в обычные экспрешны.
Анонимные классы:
Здесь по аналогии с лямбдами генерируется класс по описанию.
сейчас нельзя написать структуру с автопропертями
K>сейчас нельзя написать структуру с автопропертями
Можно
S>Здравствуйте, k0st1x, Вы писали:
K>>сейчас нельзя написать структуру с автопропертями
S>Можно
S>
спасибо : ) не знал про этот странный нюанс.
но все равно есть, что улучшать : )
было бы здорово, чтобы вообще без дополнительного вызова.
K>спасибо : ) не знал про этот странный нюанс.
K>но все равно есть, что улучшать : )
K>было бы здорово, чтобы вообще без дополнительного вызова.
Этого вызова по факту не существует.
K>Здравствуйте, samius, Вы писали:
S>>Можно
S>>
K>спасибо : ) не знал про этот странный нюанс.
Ничего странного. Если рассахарить и ввести поле, то компилятор точно так же не дает обращаться к сеттеру свойства, пока не будут проиницилизированы все поля. Либо явно инициализируем введенное поле, либо неявно (вызываем конструктор по умолчанию).
K>но все равно есть, что улучшать : )
K>было бы здорово, чтобы вообще без дополнительного вызова.
Уверен что дополнительного вызова нет.
K>спасибо : ) не знал про этот странный нюанс.
Хотя о нём явно написано в спеке: 10.7.3 Automatically implemented properties
Хз, можно ли это красиво сделать без правок в CLR, но фича полезная и логичная была бы.
В Java есть, AFAIR.
J>Здравствуйте, AndrewVK, Вы писали:
J>Хз, можно ли это красиво сделать без правок в CLR, но фича полезная и логичная была бы.
J>
J>В Java есть, AFAIR.
имхо, для такого кода хорошо подходят дженерики
K>имхо, для такого кода хорошо подходят дженерики
Ну и получится у класс с N дженерик параметрами, N — количество виртуальных не-void методов. Не страшно?
J>Здравствуйте, AndrewVK, Вы писали:
J>Хз, можно ли это красиво сделать без правок в CLR, но фича полезная и логичная была бы.
J>
J>В Java есть, AFAIR.
А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ? Вариантность вообще-то к дженерикам относится. А тут непонятно что.
G>А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ?
Не что не мешает. Точно так же как ничто не мешает в наследнике MyCollection2: MyCollection в CreateItem вернуть CollectionItem. А по идее — компилятор должен мешать.
G>Вариантность вообще-то к дженерикам относится.
Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".
J>Здравствуйте, gandjustas, Вы писали:
G>>А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ?
J>Не что не мешает. Точно так же как ничто не мешает в наследнике MyCollection2: MyCollection в CreateItem вернуть CollectionItem. А по идее — компилятор должен мешать.
Кому должен? Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
Вообще есть вероятность нарушения LSP при таком поведении.
G>>Вариантность вообще-то к дженерикам относится.
J>Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".
http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
G>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
вот это уже ковариантность.
И это тоже. Дженериков нет, ковариантность есть.
S>И это тоже.
Тут я немного нагнал, нужны reference типы. Для строк работает, для int-ов — нет.
S>Здравствуйте, gandjustas, Вы писали:
G>>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
S>
S>вот это уже ковариантность.
Да ну? А где здесь функтор?
S>
S>И это тоже. Дженериков нет, ковариантность есть.
Array всегда был недодженериком. И эта ковариантность очень опасна, ведь можно сделать так:
G>Здравствуйте, samius, Вы писали:
S>>
S>>вот это уже ковариантность.
G>Да ну? А где здесь функтор?
А зачем функтор?
S>>И это тоже. Дженериков нет, ковариантность есть.
G>Array всегда был недодженериком. И эта ковариантность очень опасна, ведь можно сделать так:
G>
Тем не менее, ковариантность массивов — формальная фича C# 1.0
G>object[] x = new int[] { 1 };
ЩИТО?
S>вот это уже ковариантность.
S>
Это просто ошибка. Ковариантность в массивах работает только для ссылочных типов. А лучше бы ее вообще не было, так как для изменяемых типов для ее поддержки требуются рантайм-проверки. Дотент не хило тормозит из-за этого, при работе с массивами.
G>Здравствуйте, Jack128, Вы писали:
J>>Здравствуйте, gandjustas, Вы писали:
G>>>А зачем? Что мешает возвращать MyCollectionItem, там где требуется CollectionItem ?
J>>Не что не мешает. Точно так же как ничто не мешает в наследнике MyCollection2: MyCollection в CreateItem вернуть CollectionItem. А по идее — компилятор должен мешать.
G>Кому должен?
программисту.
G>Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
G>Вообще есть вероятность нарушения LSP при таком поведении.
"такое поведение" — это поведение MyCollection2? естественно нарушит LSP. И именно этого и поможет избежать предлагаемая фича.
G>>>Вариантность вообще-то к дженерикам относится.
J>>Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".
G>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
а какой реальности идет речь, если вариантность — понятие из абстрактной математики? то что ты в курсе только о вариантности делегатов и интерфейсов не означает, что это понятие нельзя применить к другим "операциям".
G>>Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
G>>Вообще есть вероятность нарушения LSP при таком поведении.
J>"такое поведение" — это поведение MyCollection2? естественно нарушит LSP. И именно этого и поможет избежать предлагаемая фича.
Как она поможет избежать? Примером кода пожалуйста.
G>>>>Вариантность вообще-то к дженерикам относится.
J>>>Перечитал несколько раз. Слова generics — не нашел. Только абстрактное "operation".
G>>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
J>а какой реальности идет речь, если вариантность — понятие из абстрактной математики? то что ты в курсе только о вариантности делегатов и интерфейсов не означает, что это понятие нельзя применить к другим "операциям".
Ты прочитал то статью? Как относится вариантность к тому что ты пишешь?
G>Здравствуйте, Jack128, Вы писали:
G>>>Ты же наследование делаешь чтобы обращаться к наследникам через ссылку на базовый класс. Соответственно непонятно зачем в наследнике менять типы, и как сообщить компилятору какой тип правильный.
G>>>Вообще есть вероятность нарушения LSP при таком поведении.
J>>"такое поведение" — это поведение MyCollection2? естественно нарушит LSP. И именно этого и поможет избежать предлагаемая фича.
G>Как она поможет избежать? Примером кода пожалуйста.
class CollectionItem {}
class Collection
{
protected virtual CollectionItem CreateItem() {...}
}
class MyCollectionItem: CollectionItem {}
class MyCollection: Collection
{
protected override MyCollectionItem CreateItem() {...}
}
class MyCollection2: MyCollection
{
// protected override CollectionItem CreateItem() {...} так ошибка компиляции, так как CollectionItem не является MyCollectionItem, ковариантность нарушится. Раз не компилируется, то LSP не сможем нарушить.
protected override MyCollectionItem CreateItem() {...} // а так вполне можно.
}
G>>>http://gandjustas.blogspot.ru/2009/11/blog-post.html вот тут посвежее и ближе к реальности.
J>>а какой реальности идет речь, если вариантность — понятие из абстрактной математики? то что ты в курсе только о вариантности делегатов и интерфейсов не означает, что это понятие нельзя применить к другим "операциям".
G>Ты прочитал то статью? Как относится вариантность к тому что ты пишешь?
ну как, твоя статья описывает частные случаи вариантности, реализованные в C#. Какая вариантность бывает в других языках — можно на вики почитать.
G>Вообще есть вероятность нарушения LSP при таком поведении.
Нет такой вероятности, если не разрешать делать тип возвращаемого значения более общим нежели был.
Ковариантность для возвращаемых значений работает в С++ и Яве.
Нельзя ли сделать так, чтобы enum'ы реализовывали интерфейс IEquatable<> ?
SAS>Здравствуйте, AndrewVK, Вы писали:
SAS>Нельзя ли сделать так, чтобы enum'ы реализовывали интерфейс IEquatable<> ?
А блоки итераторов — интерфейс ICloneable<>.
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
вместо
FE>
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
К сожалению, необходимость умным людям придумывать себе работу, портит коммерческие языки программирования. В C# есть некоторые недостатки, но они не так важны.
На мой взгляд, на данном этапе команду C# надо занять трудоёмкой и полезной работой, которая не приведёт к бесконтрольному росту языка.
Я бы предложил им переписать компилятор, чтобы намного сильнее увеличить уровень оптимизации. Что-то типа LTCG (именно на уровне байт кода) было бы здорово получить.
X>Я бы предложил им переписать компилятор, чтобы намного сильнее увеличить уровень оптимизации.
Основные оптимизации в дотнете производит не компилятор, а джит. И да, компилятор уже переписан.
X> Что-то типа LTCG (именно на уровне байт кода) было бы здорово получить.
Жди СТР нового JITа.
X>>Я бы предложил им переписать компилятор, чтобы намного сильнее увеличить уровень оптимизации.
AVK>Основные оптимизации в дотнете производит не компилятор, а джит.
Вот и я про то же. Основной бич программ на байт коде — время запуска. Конечно, MS очевидно хочет, чтобы в будущем весь софт выгружался с marketplace уже скомпилированный Ngen-ом. Но на ближайшие лет десять могли бы написать универсальный оптимизатор именно байт-кода, который производил бы тот же байт код.
X>> Что-то типа LTCG (именно на уровне байт кода) было бы здорово получить.
AVK>Жди СТР нового JITа.
В принципе, если все найденные на жестких, сетевых и съемных дисках пользователя .Net программы будут заранее компилироваться операционной системой и складываться в некий кэш, то необходимость в оптимизации на уровне языка отпадет навсегда.
P.S. Поясните, плиз, лучше про компилятор, который "уже" переписали? Уже это когда? И что именно переписали?
X>Конечно, MS очевидно хочет, чтобы в будущем весь софт выгружался с marketplace уже скомпилированный Ngen-ом.
При чем тут marketplace? Ngen прекрасно работает с любыми дотнетными сборками.
X> Но на ближайшие лет десять могли бы написать универсальный оптимизатор именно байт-кода, который производил бы тот же байт код.
Это малоэффективно, потому что большая часть оптимизаций для императивных языков требует знания архитектуры процессора.
AVK>>Жди СТР нового JITа.
X>В принципе, если все найденные на жестких, сетевых и съемных дисках пользователя .Net программы будут заранее компилироваться операционной системой и складываться в некий кэш, то необходимость в оптимизации на уровне языка отпадет навсегда.
Оно уже именно так и работает.
X>P.S. Поясните, плиз, лучше про компилятор, который "уже" переписали? Уже это когда? И что именно переписали?
Компилятор. Полностью. На C#. Это одна из составных частей Розлина.
AVK>При чем тут marketplace? Ngen прекрасно работает с любыми дотнетными сборками.
Неверно. Для ngen требуются административные права. Это приводит к невозможности его использования в моих приложениях. Для меня ngen'a — нету.
GZ>Неверно. Для ngen требуются административные права.
Для инсталляторов обычно тоже.
GZ> Это приводит к невозможности его использования в моих приложениях.
Современные фреймворки запускают ngen для часто используемых сборок самостоятельно, в том числе и для твоих продуктов.
GZ>>Неверно. Для ngen требуются административные права.
AVK>Для инсталляторов обычно тоже.
Ваще-то нет. Всё прекрасно ставится в профайл, и прекрасно работает в терминалках.
Ладно, я вполне понимаю зачем они требуют для ngen — full trust. На здоровье, мне на это наплевать. Но зачем требовать административных прав для запуска ngen, когда он спокойно компилируется в профайл — мне непонятно.
GZ>> Это приводит к невозможности его использования в моих приложениях.
AVK>Современные фреймворки запускают ngen для часто используемых сборок самостоятельно, в том числе и для твоих продуктов.
Таких эффектов замечено не было. Где почитать?
X>>Я бы предложил им переписать компилятор, чтобы намного сильнее увеличить уровень оптимизации.
AVK>Основные оптимизации в дотнете производит не компилятор, а джит.
Похоже, что ничего за 10 лет не изменилось.
Те, кто делают компилятор думают, что оптимизировать будет джит.
А те, кто делают джит — оптимизацией не занимаются, чтобы не тормозил запуск приложений.
В результате все в пролете.
X>> Но на ближайшие лет десять могли бы написать универсальный оптимизатор именно байт-кода, который производил бы тот же байт код.
AVK>Это малоэффективно, потому что большая часть оптимизаций для императивных языков требует знания архитектуры процессора.
Очень жаль, если команда дотнета так считает.
Значит никаких высокоуровневых оптимизаций просто не будет.
Как джит поможет превратить вот это:
например в это:
последовательно совершив инлайнинг лямбды внутрь ForEach, затем превратив ForEach в for, вытащив массив изнутри списка и выкинув проверки на границы массива в индексаторе?
А ведь это только одна из элементарных оптимизаций, которые хотелось бы видеть в дотнете.
Да просто чтобы развернуть цикл или сделать глобальный сквозной инлайнинг (чтобы схлопнуть многоуровневые вызовы мелких фукций) — разве надо знать архитектуру процессора?
Но очевидно, ничего этого не будет, пока оптимизацией
делает вид чтозанимается джит.И при чем тут императивные языки, если в дотнете сейчас тормозит вообще все?
Начиная от базовых вещей типа рефлекшена и сериализации, и заканчивая библиотеками вроде WPF.
Тут оптимизировать надо абсолютно все и на всех уровнях.
Оптимизатор уровня байт-кода, про который говорит Xentrax — как раз во многом помог бы.
Например, генерацией дополнительного кода (для рефлекшона/сериализации), выкидыванием лишних проверок (проанализировав, что они не нужны), трансформацией одних конструкций в другие, тотальным инлайнингом и т.п.
И в частности это решило бы вечную проблему, кто должен оптимизировать: джит или компилятор.
PS: а по теме — ничего от С# не надо, пока приходится для всех объектов писать самопальную (зато быструю и компактную) сериализацию да переписывать код в стиле С, когда скорость нужна.
S>PS: а по теме — ничего от С# не надо, пока приходится для всех объектов писать самопальную (зато быструю и компактную) сериализацию да переписывать код в стиле С, когда скорость нужна.
Попробуй немерле. То о чем ты говоришь, на макросах автоматизируется на раз.
S>Как джит поможет превратить вот это:
S>
S>например в это:
S>
S>последовательно совершив инлайнинг лямбды внутрь ForEach, затем превратив ForEach в for, вытащив массив изнутри списка и выкинув проверки на границы массива в индексаторе?
S>А ведь это только одна из элементарных оптимизаций, которые хотелось бы видеть в дотнете.
я против "инлайнинга из коробки".
лично мне важно, чтобы stack trace совпадал с исходниками
K>я против "инлайнинга из коробки".
K>лично мне важно, чтобы stack trace совпадал с исходниками
Для этого давно придуманы debug и release.
К слову, где то слышал, что ngen и jit оптимизируют абсолютно одинаково. это так??
Не
а
или ещё лучше в base64 (24 символа)
O>или ещё лучше в base64 (24 символа)
Стесняюсь спросить — а зачем?
Я бы ещё понял compile-time checking гуидных констант.
Но он сам по себе никак не требует переписывания кода — я бы скорее попросил валидации всех выражений new Guid(expr), если expr резолвится в string constant.
А экономить десяток байт в ущерб читаемости, имхо, нездоровая идея.
S>Стесняюсь спросить — а зачем?
Меньше занимает места на экране.
O>Меньше занимает места на экране.
Омг. Если вам неважно это значение, схлопните регион, в котором оно.
А если важно, и их несколько в строке?
S>>Если вам неважно это значение, схлопните регион, в котором оно.
O>А если важно, и их несколько в строке?
Если важно, то base64 — отвратительная идея. Хуже неё — только base64 от gzip от guid.
А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).
S>>Стесняюсь спросить — а зачем?
O>А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).
Двойной щелчок перед открывающей кавычкой пробовали?
Неудобно, нужно точно попадать и кавычки отрезАть потом (чтобы, например, в sql-запрос вписать).
S>>Стесняюсь спросить — а зачем?
O>А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).
ОМГ. То есть вы предлагаете вместо починки IDE починить язык? Ну-ну.
Зачем делать не-интуитивнопонятные выкрутасы в иде, если можно сделать чётко и лаконично в языках?
O>Зачем делать не-интуитивнопонятные выкрутасы в иде, если можно сделать чётко и лаконично в языках?
Затем, что каждому своё.
Язык нужен для того, чтобы его было легко читать человеку.
IDE нужна для того, чтобы на этом легкочитаемом языке было легко писать.
S>>Стесняюсь спросить — а зачем?
O>А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).
Это элементарно исправляется
выкидыванием мышиустановкой VsVim. Выделение строки: vi". Всё просто!S>>Стесняюсь спросить — а зачем?
O>А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).
Resharper: Ctrl+W. И несколько раз до расширения выделения до нужных границ.
O>
И как понять компилятору: это guid или переменная?
Зарезервируем все guid-ы?
По длине
O>Записывать guid без кавычек и прочих выкрутасов, как обычное число.
Еще один literal of the day с применением 1 штука на мегабайт кода?
O>>Записывать guid без кавычек и прочих выкрутасов, как обычное число.
AVK>Еще один literal of the day с применением 1 штука на мегабайт кода?
Как насчёт 0x синтакса из T-SQL?
Кстати да. Реализовать поддержку Int128, и не понадобится в языке изобретать ничего нового.
Очень хотелось бы Dispose по exception. Пример, примерно такой:
Синтаксический сахар вырождается примерно в структуру:
Доработка простая как 2 копейки. Но периодически её сильно не хватает.
Ручной полиморфизм иногда пригождается. Кроме того он более управляем, чем перегрузка методов.
Из мелкого мне бы хотелось возможность наследовать парралельные ветки:
Из крупного хочется мочь создавать доменные языки сразу в коде, на пример пусть я хочу чтобы, у Dictionary можно было указывать название свойств вместо Key и Value, для этого делаю свою лексему:
И какой-нибудь механизм, позволяющий писать дженерики, принимающие только numeric-типы, например (общем случае реализующие какой-то набор операторов).
Сокращенная форма того же самого:
Или существующий keyword приспособить, например, new
S_S>Сокращенное написание такого проперти:
Эта фича чаще всего запрашивается. Мэдс пару вариантов синтаксиса показывал, но там довольно много всяких побочных вопросов.
F>Еще добавить полноценную поддержку MMX/SSE для оптимизации вычислений с плавающей точкой.
Это возможно реализовать только с изменением рантайма, сам язык для поддержки интринзиков менять не нужно. В Mono такое сделали, но я даже не уверен что этим API кто-либо пользуется.
H>Это возможно реализовать только с изменением рантайма, сам язык для поддержки интринзиков менять не нужно. В Mono такое сделали, но я даже не уверен что этим API кто-либо пользуется.
Мало ли, вдруг и рантайм обновят. Сравнения производительности вычислений на c++ и c# гуглятся и показывают дикое отставание последнего. Игнорирование MMX/SSE — одна из далеко не последних причин.
H>Это возможно реализовать только с изменением рантайма, сам язык для поддержки интринзиков менять не нужно. В Mono такое сделали, но я даже не уверен что этим API кто-либо пользуется.
Однозначно в рантайме. Иначе маршаллинг съест нафиг всё преимущество параллельного вычисления.
F>Еще добавить полноценную поддержку MMX/SSE для оптимизации вычислений с плавающей точкой.
Должно быть в следующей версии JIT.
AVK>Должно быть в следующей версии JIT.
А хотя бы ориентировочные сроки выхода есть? (2013, 2014, ...)?
AVK>>Должно быть в следующей версии JIT.
QL>А хотя бы ориентировочные сроки выхода есть? (2013, 2014, ...)?
СТР должен быть скоро. А что касается релиза — у меня никаких данных нет.
1. constraint на enum.
2. public int MyProp { get; set; } = 10 (задалбался для этого заводить конструктор)
3. (почти как 2). Дать возможность инициализировать поля как private MyContainer _containter = new MyContainer(this);
4. var f = x => x + 1; Хочется, чтобы был авто-вывод к Func и Action
Partial attributes? Чтобы атрибуты на член класса можно было указывать в разных файлах.
2) Модули из CLR
3) свитчи по типам
4) кейс-инсенситив свитч (инвариант)
5) Вычисляемые строки как в повершелле ("@var") — пусть хотя бы и с возможностью использования только переменных и полей в области видимости.
6) catch нескольких типов сразу catch(IOException, FileNotFoundException){}
7) internals visible only to на уровне классов (для проектов, у которых одна большая ДЛЛ и не хочется "делиться" внутренностями класса со всеми)
8) Байндинг одного алиаса к нескольким неймспейсам.
1) Возврат множества значений из функции, что-нибудь типа:
2) Более мощная система ограничений для дженериков, в частности ограничения на поддержку перегруженных операторов
3) Дефолтные реализации методов в интерфейсах (что-то типа трейтов)
4) Null safety — not nullable types.
Что-то типа
Хейлсберг говорил в интервью, что они этого не делают, потому что при использовании в существующих библиотеках это поломает совместимость. Но кто мешает не использовать эту фичу в старых апи?
5) Упрощенный синтаксис для лямбд без параметров или с одним параметром, по типу того, как сделано в Котлине. Чтобы там, где ожидается лямбда, можно было бы писать ее без лишних скобок
чтобы вместо
было
а если еще и позволить использовать операторный синтаксис для методов с одним параметром, то можно даже так:
6) Ну и главная хотелка это конечно мета-программирование, хотя бы для простейших случаев:
Но это, как я понимаю, выходит за рамки вопроса о небольших улучшениях.
ЕА>5) Упрощенный синтаксис для лямбд без параметров или с одним параметром, по типу того, как сделано в Котлине. Чтобы там, где ожидается лямбда, можно было бы писать ее без лишних скобок
ЕА>чтобы вместо
ЕА>
ЕА>было
ЕА>
ЕА>[/c#]
По-моему, дикость. Что если метод, подобный Where, будет принимать boolean в одной из своих перегрузок?
Ц>По-моему, дикость. Что если метод, подобный Where, будет принимать boolean в одной из своих перегрузок?
В Немерле решается использованием подчёркивания вместо имени переменной. Причём, работает и для лямбд с несколькими параметрами:
DR>Здравствуйте, Цыба, Вы писали:
Ц>>По-моему, дикость. Что если метод, подобный Where, будет принимать boolean в одной из своих перегрузок?
DR>В Немерле решается использованием подчёркивания вместо имени переменной. Причём, работает и для лямбд с несколькими параметрами:
DR>
Жопа какая-то :D
Что бы можно было написать так.
и не получить
User-defined conversion must convert to or from the enclosing type
А>Здравствуйте, AndrewVK, Вы писали:
А>Что бы можно было написать так.
хотя бы внутри
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам. Желательно раскрыть мысль поподробнее.
...
исправить наконец компилятор и сделать using abort безопасными. что бы в случае остановки потока abort-ом ресурсы гарантированно освобождались.
сделать префиксы по умолчанию что бы короче писать
из тойже оперы. чтобы можно было не уразывать каждый раз название enum
задание поведения при невозможности вычисления выражения (не только null exception но и например пропускать код)
по принципу isset из php: isset( $a[1][2][3][4][5][6][7][8] )
подстановка кода например
сделать обытия для свойств помимо get_ set_ методов еще event_ событие было по изменению
иногда хочется вот такой вот порнографии
Не хватает такого синтаксиса в определения методов класса
Дозадание функций (регулярных выражений не прошу)
Динамический switch
Очень не хватает контекста для функций и свойств
Не хватает простой авто генерации кода
Вобщем нехватает макросов как так чтоб можно было генерить исходный текст параметрически.
Смиренный программист (EWD340) Эдсгер Дейкстра 1972г.
Ничего не напоминает? Действительно, история развивается по спирали...
D>Ничего не напоминает? Действительно, история развивается по спирали...
Не напоминает. Фичи фичам рознь. Например, в том же PL/1 для того, чтобы сделать возможность вызывать функцию рекурсивно, нужно было помечать её особым ключевым словом. Вот такие там в основном были фичи. Ничего общего с тем что здесь обсуждается.
IT>Здравствуйте, Didi, Вы писали:
D>>Ничего не напоминает? Действительно, история развивается по спирали...
IT>Не напоминает. Фичи фичам рознь. Например, в том же PL/1 для того, чтобы сделать возможность вызывать функцию рекурсивно, нужно было помечать её особым ключевым словом. Вот такие там в основном были фичи. Ничего общего с тем что здесь обсуждается.
Ну, в C# тоже достаточно революционных фич а-ля partial methods.
IT>>Не напоминает. Фичи фичам рознь. Например, в том же PL/1 для того, чтобы сделать возможность вызывать функцию рекурсивно, нужно было помечать её особым ключевым словом. Вот такие там в основном были фичи. Ничего общего с тем что здесь обсуждается.
ARK>Ну, в C# тоже достаточно революционных фич а-ля partial methods.
Весьма полезная штукенция, если речь идёт о генерации кода. При наличии полноценного МП, конечно, рудимент, но до полноценного МП нам ещё как до Парижу.
AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.
конструкцию assume такого вида:
Просто что бы внутри блока проверяло условие перед использованием или при изменении значения переменной(ых) и выполняло заданное действие.
Что бы не писать так:
Хотелось бы вложенных функций
P>чего не хватает так это множественного наследования, просто за основу программирования взята математическая модель с ее иерархическими цепочками от частного к общему, с другой стороны должны же когдато предоставить возможность множественного кроссовера как например делается с растениями или в генетическом алгоритме — это был бы прорыв
Я против
А>Здравствуйте, pavel783, Вы писали:
P>>чего не хватает так это множественного наследования
А>Я против
Не беспокойтесь, изменениями в C# этот вопрос не решить. Тут нужно рантайм менять.
P>чего не хватает так это множественного наследования, просто за основу программирования взята математическая модель с ее иерархическими цепочками от частного к общему, с другой стороны должны же когдато предоставить возможность множественного кроссовера как например делается с растениями или в генетическом алгоритме — это был бы прорыв
Это уже проходили в С++. При среднем уровне программиста вреда от множественного наследования больше, чем пользы, да и ногу отстрелить себе значительно легче. За 10 лет программирования на .Net как-то не возникало задачи, требующей множественное наследование.
P> возможность множественного кроссовера как например делается с растениями или в генетическом алгоритме — это был бы прорыв
Кроссинговера, наверное. А вообще, как уже написали — не нужно.
А>Автоматические свойства, с возможностью изменения только из конструктора.
А>
Два слова тут лишние: initonly и set. Именно так сделано в Nemerle.
Например так:
В фигурных скобках декларация членов как в описании интерфейса (может с модификаторами доступа public protected private), эти члены появляются в классе, реализуются как обертки над членами _member.
Т.е раскрываются в такое