Re[4]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 09:27
Оценка: +3 -4 :))
Здравствуйте, hardcase, Вы писали:

H>Откровенно говоря подобное API появилось из-за отсутствия в языке опциональных значений и кортежей а так же возможностей по их декомпозиции.

Нафиг не нужны они в шарпе. Точно так же как и тюплы, если честно.
И то и то — инструмент для API на выброс, где накосячил — ну и ладно.

В взрослых проектах выгодней один раз заморочиться с API, но после этого не писать подобный треш:
when (double.Parse(text) is Some(value))
{
  WriteLine(value);
}

в сотнях и тысячах мест после каждого вызова. Мы уже проходили эти грабли с HRESULT. Мало что ли?
[Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 08:16
Оценка: 83 (8)
Всё-таки забавные вещи по рассылке приплывают.

Вроде всё как обычно, xproj->csproj, value tasks, .NET Core Tooling, а затем внезапно такой список:

Languages (available for .NET Framework and .NET Core)


Bring functional programming concepts to .NET languages
* Tuples
* Pattern matching

Performance and Code Quality
* Value Tasks
* Ref returns
* Throw expressions
* Binary literals
* Digit separators

Developer Productivity
* Out vars
* Local functions


Нужное выделил ссылкой. Забавно всё-таки, фича сначала не попала в релиз c# 6, затем попала в планы на c# 8, затем внезапно переехала в седьмой шарп.
Там ещё новостей есть, чтоб не портить удовольствие — сами читайте :P

Ну и чтоб два раза не вставать: c# 7 work list of features опять обновили, теперь в нём помимо pattern matching акцент на кодогенерацию. Ох уж эти сказочники...
Re[3]: [Ann] .Net Core roadmap
От: hardcase Пират http://nemerle.org
Дата: 18.07.16 08:53
Оценка: +5
Здравствуйте, Sinix, Вы писали:

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


G>>Костыль! Функция не должна возвращать значение через входные параметры.

S>Не всё, чего нет в %мой_любимый_язык%, является костылём

S>С интересом жду более читабельного варианта для

S>
S>if (double.TryParse(text, out var parsed))
S>{
S>  // use parsed value here.
S>}
S>


Откровенно говоря подобное API появилось из-за отсутствия в языке опциональных значений и кортежей а так же возможностей по их декомпозиции.
when (double.Parse(text) is Some(value))
{
  WriteLine(value);
}
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: [Ann] .Net Core roadmap
От: Jack128  
Дата: 18.07.16 09:37
Оценка: +4
Здравствуйте, Sinix, Вы писали:


S>В взрослых проектах выгодней один раз заморочиться с API, но после этого не писать подобный треш:

S>
S>when (double.Parse(text) is Some(value))
S>{
S>  WriteLine(value);
S>}
S>

S>в сотнях и тысячах мест после каждого вызова. Мы уже проходили эти грабли с HRESULT. Мало что ли?

А можно пояснить, чем Option<double> TryParse(string s) трешовее bool TryParse(string s, out double value)?

Update:
Просто я не могу понять эту логику:
1) Вводим тучу методов, а-ля TryParse(string s, out XXX value)
2) Вводим в язык ПМ.
3) Вместо того, чтоб добавить Option<XXX> TryParse(string s), который отлично ложится на пункт 2), вводим в язык новую конструкцию, облегчающую использование исходного TryParse
Отредактировано 18.07.2016 9:51 Jack128 . Предыдущая версия .
Re[6]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 09:57
Оценка: -4
Здравствуйте, Jack128, Вы писали:

J>А можно пояснить, чем Option<double> TryParse(string s) трешовее bool TryParse(string s, out double value)?


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

Как обычно, возможность сделать выбор на практике означает необходимость делать выбор: пользователи будут вынуждены или писать дополнительные костыли в виде match, или пробрасывать Option дальше, заражая весь код так же, как это делает await. Только от последнего пользы на порядок больше.

В общем идея странная, особенно если учитывать, что у шарпа уже есть удобный синтаксис для nullable values и с введением not null references необходимость в Option отпадёт окончательно.
Re[5]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:29
Оценка: +4
Здравствуйте, Sinix, Вы писали:

S>В взрослых проектах выгодней один раз заморочиться с API, но после этого не писать подобный треш:

S>
S>when (double.Parse(text) is Some(value))
S>{
S>  WriteLine(value);
S>}
S>


Трешь — это что приходится писать в Шарпе сейчас. На фиг искать разные извращения, когда хороший выход из ситуации придуман 30 лет назад?

Единсвенное что нужно сделать — это сделать так, чтобы кортежи были дешевы в применении, чтобы люди не экономили на их использовании. Если сделать как в F#, т.е. генерить код с аут/реф-параметры, а в синтаксисе представлять такие функции как возвращающие кортеж, то получится и быстро, и красиво.

Ну, а ты немного поменяешь привычку и потом с улыбкой этот свой пост будешь вспоминать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:25
Оценка: 26 (3)
Здравствуйте, Sinix, Вы писали:

S>С интересом жду более читабельного варианта для

S>
S>if (double.TryParse(text, out var parsed))
S>{
S>  // use parsed value here.
S>}
S>


Я бы предпочел F#-пный вариант, когда функция с out-параметрами автоматически преобразуется к реверси возвращающий кортеж.
if (double.TryParse(text) is (true, parsed))
{
  // use parsed value here.
}


S>Ну и чтоб два раза не вставать, ваш аналог для ref?


Тоже что и в прошлом случае, но для ref-параметр не удаляется из сигнатуры, а заменяется на не ref.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] .Net Core roadmap
От: HeBpuMHeCkaTuHa СССР  
Дата: 20.07.16 07:33
Оценка: 15 (2) +1
S>
S>when (double.Parse(text) is Some(value))
S>{
S>  WriteLine(value);
S>}
S>


пример не совсем удачный. в то й же Scala это выглядит удобнее:

double.parse(text).flatMap(WriteLine)

Options в купе с паттерн матчингом реально очень удобно.
Нет времени на раскачку!
Re[7]: [Ann] .Net Core roadmap
От: HeBpuMHeCkaTuHa СССР  
Дата: 20.07.16 08:18
Оценка: 12 (1) +2
HBM>>double.parse(text).flatMap(WriteLine)

S>Ну так оно удобно только для мелочёвки из легаси-кода, которая в extension methods не умеет.

S>Для всего остального или ?.WriteLine (совместно с private extension methods покрывает почти все сценарии), или ждём pipe operator.

Если Pipe Operator появится, это будет мега круто.

Что до "элвис-оператора", то это просто синтаксический сахар и костыль из-за отсутствия Options Type.
Нет времени на раскачку!
Re[7]: [Ann] .Net Core roadmap
От: hardcase Пират http://nemerle.org
Дата: 18.07.16 11:45
Оценка: +3
Здравствуйте, Sinix, Вы писали:

S>Ну это классический косяк дизайна aka перекидывание ответственности на пользователя. Вместо того, чтоб лишить пользователя выбора и сделать проверку частью вызова, мы разделяем их на отдельные сущности.


У пользователя и так есть выбор: Parse vs TryParse. А также есть выбор написать TryParse без проверки успешности разбора. В случае с вариантным значением у него вообще не будет выбора написать код без проверки результата. Но это все уже совсем иная история и не про C#.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:30
Оценка: +1 :))
Здравствуйте, Sinix, Вы писали:

S>Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.


Традиции нельзя нарушать. Так что должно вылезти.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:42
Оценка: +3
Здравствуйте, Sinix, Вы писали:

S>Ну это классический косяк дизайна aka перекидывание ответственности на пользователя. Вместо того, чтоб лишить пользователя выбора и сделать проверку частью вызова, мы разделяем их на отдельные сущности.


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

S>Как обычно, возможность сделать выбор на практике означает необходимость делать выбор: пользователи будут вынуждены или писать дополнительные костыли в виде match, или пробрасывать Option дальше, заражая весь код так же, как это делает await. Только от последнего пользы на порядок больше.


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

Текущее решение позволяет спокойно (в том числе и случайно) опускать проверку наличия значения. Приседание с объявлением переменной в аргументе как раз и вводится, чтобы упростить жизнь людям. Именно по этому ограничивается область видимости переменной (if-ом).

Кортеж и ПМ — это более универсальное решение не требующее костылей вроде этого. Оно заставляет проверить наличие значения перед его использованием и сокращает количество сущностей которые нужно контролировать.

S>В общем идея странная, особенно если учитывать, что у шарпа уже есть удобный синтаксис для nullable values и с введением not null references необходимость в Option отпадёт окончательно.


В этом плане удобного в Шарпе ничего не. В нем есть набор косяков и попытки нивелировать их костылями.

А вот как раз кортежи + паттерн матчинг — это удобно, проверенное временем и концептуально чистое решение. Просто ты к нему не привык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] .Net Core roadmap
От: hi_octane Беларусь  
Дата: 19.07.16 09:11
Оценка: 2 (1) :)
S>А что N MS уже в VS встраивает? Что то я не видел при инсталяции предложения поставить N
Это было бы слишком просто. А индусам надо двух-годовые роадмапы и мильонные бюджеты осваивать. Поэтому они просто перетягивают фичи из N(и других языков), по одной в мажорный релиз Ну и раз в несколько лет делают адовую копипасту под видом создания другой платформы (.NET Fw CE, Silverlight, Client Profile, Portable, сейчас вот Core).
Re[7]: [Ann] .Net Core roadmap
От: Jack128  
Дата: 18.07.16 11:47
Оценка: 1 (1) +1
Здравствуйте, Sinix, Вы писали:

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


J>>Update:

J>>Просто я не могу понять эту логику:
J>>1) Вводим тучу методов, а-ля TryParse(string s, out XXX value)
J>>2) Вводим в язык ПМ.
J>>3) Вместо того, чтоб добавить Option<XXX> TryParse(string s), который отлично ложится на пункт 2), вводим в язык новую конструкцию, облегчающую использование исходного TryParse

S>То, что у тебя появился новый инструмент вовсе не означает необходимость использовать.


S>Не, есть конечно ортодоксы, которые предпочитают всегда и везде использовать var
Автор: Sinix
Дата: 02.04.16
или method group
Автор: Sinix
Дата: 04.03.11
, ловить грабли с extension methods
Автор: Sinix
Дата: 20.04.16
или с string interpolation
Автор: Sinix
Дата: 31.03.16
и тыды и тыпы. Причём не по какой-то объективной причине, а просто потому что фишка появилась / анализ кода посоветовал.


S>Но это не значит, что остальным надо поступать так же.


S>Сравни сам

S>
S>if (double.TryParse(text, out var parsed))
S>{
S>  WriteLine(parsed);
S>}

S>// vs
S>if (double.TryParse(text) is Some(var parsed)) // в c#7/8 оно примерно так выглядит
S>{
S>  WriteLine(parsed);
S>}
S>

S>Про то, как будет выглядеть метод с парой out — не советую. Съедят

if (MyParser.TryParse(text, out var left, out var right) { WriteLine($"{left} - {right}") }
if (MyParser.TryParse(text) is Some(var parsed)) { WriteLine($"{parsed.Left} - {parsed.Right}") }

не, те хочется сразу по переменным разложить parsed, то по идее, что то такое должно сработать:
if (MyParser.TryParse(text) is Some (( var left, var right ))) { WriteLine($"{left} - {right}") } // ага, двойные скобки -)

Ну и два out параметра сами по себе тот еще запашок имеют..


Ну из твоих примеров, я вижу, что лучший вариант, использование Nullable + допилить PM, чтоб это был PM, а не тупой typetest.
Тогда можно было и так:
var data = WebHelpers.TrySendRequest(param)?.Result.SomeField?.ToString();

и так писать:
if (MyDouble.TryParse(text) is (true, var parsed)) // double? MyDouble.TryParse(string text)
{
   WriteLine(parsed);
}


А на счет out var, если я правильно понял, то if (int.TryParse(str, out var value) {} — value видно только внутри скобок
Тогда такой код:
    if (!int.TryParse(str, out var value)) return false;
    // тут юзаем value


будет в пролете. Если так, то уж совсем криво этот синтаксис выглядит.
Отредактировано 18.07.2016 21:08 Jack128 . Предыдущая версия .
Re: [Ann] .Net Core roadmap
От: Gattaka Россия  
Дата: 18.07.16 08:29
Оценка: +2
S>Developer Productivity
S>* Out vars
S>* Local functions
S>[/q]

Костыль! Функция не должна возвращать значение через входные параметры.
Отредактировано 19.07.2016 3:37 Gattaka . Предыдущая версия . Еще …
Отредактировано 19.07.2016 3:37 Gattaka . Предыдущая версия .
Re[6]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 20.07.16 07:53
Оценка: 8 (1)
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:

HBM>double.parse(text).flatMap(WriteLine)


Ну так оно удобно только для мелочёвки из легаси-кода, которая в extension methods не умеет.
Для всего остального или ?.WriteLine (совместно с private extension methods покрывает почти все сценарии), или ждём pipe operator.
Re[2]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 09:29
Оценка: 6 (1)
Здравствуйте, Serginio1, Вы писали:

S>Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2

Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.
Re[6]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 11:03
Оценка: 1 (1)
Здравствуйте, Jack128, Вы писали:

J>Update:

J>Просто я не могу понять эту логику:
J>1) Вводим тучу методов, а-ля TryParse(string s, out XXX value)
J>2) Вводим в язык ПМ.
J>3) Вместо того, чтоб добавить Option<XXX> TryParse(string s), который отлично ложится на пункт 2), вводим в язык новую конструкцию, облегчающую использование исходного TryParse

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

Не, есть конечно ортодоксы, которые предпочитают всегда и везде использовать var
Автор: Sinix
Дата: 02.04.16
или method group
Автор: Sinix
Дата: 04.03.11
, ловить грабли с extension methods
Автор: Sinix
Дата: 20.04.16
или с string interpolation
Автор: Sinix
Дата: 31.03.16
и тыды и тыпы. Причём не по какой-то объективной причине, а просто потому что фишка появилась / анализ кода посоветовал.

Но это не значит, что остальным надо поступать так же.

Сравни сам
if (double.TryParse(text, out var parsed))
{
  WriteLine(parsed);
}

// vs
if (double.TryParse(text) is Some(var parsed)) // в c#7/8 оно примерно так выглядит
{
  WriteLine(parsed);
}

Про то, как будет выглядеть метод с парой out — не советую. Съедят


Ну, или (для switch — псевдокод, синтаксис может поменяться):
var data = WebHelpers.TrySendRequest(param)?.Result.SomeField?.ToString();

// vs
var data = WebHelpers.TrySendRequest(param) switch(
    case None: None.From<string>();
    case Some x: x.Result.SomeField switch(
        case None y: y;
        case Some z: z.ToString()));

и теперь представляем, что второй вариант будет использоваться по всему коду. Т.е. не один раз в порядке "вау, мы умеем в PM", а в сотнях и тысячах мест и что поддерживать этот праздник жизни тебе. Впечатлило?

Ну так вот, перед тем, как что-то предлагать, надо хорошо представлять что в результате получится. А то как всегда, "но я же хотел совсем не этого", ага.
Re[2]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 08:44
Оценка: +1
Здравствуйте, Gattaka, Вы писали:

G>Костыль! Функция не должна возвращать значение через входные параметры.

Не всё, чего нет в %мой_любимый_язык%, является костылём

С интересом жду более читабельного варианта для
if (double.TryParse(text, out var parsed))
{
  // use parsed value here.
}


Ну и чтоб два раза не вставать, ваш аналог для ref?
Re[2]: Оффтопик от граммар-наци
От: Qbit86 Кипр
Дата: 18.07.16 11:39
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2

S>Если поставить .NetStandart1.5 ругается на ошибки Object неопределен.
S> Когда .Net Core будет соответствовать .NetStandart1.6, или что нужно сделать, что бы студия понимала .NetStandart1.5, так как .Net 4.6.2 не нужен.

Слово «standard» в английском пишется с буквой «d» на конце.
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: Grouping them together
От: Qbit86 Кипр
Дата: 19.07.16 00:31
Оценка: +1
Здравствуйте, Sinix, Вы писали:

J>>А можно пояснить, чем Option<double> TryParse(string s) трешовее bool TryParse(string s, out double value)?

S>Ну это классический косяк дизайна aka перекидывание ответственности на пользователя. Вместо того, чтоб лишить пользователя выбора и сделать проверку частью вызова, мы разделяем их на отдельные сущности.

Вариант с `Try*(out)` не обязывает пользователя делать проверку. При отстутсвии проверки в этом случае всё будет хуже: вместо сообщения о разыменовании пустого опциона, пользователь продолжит работать с дефолтным значением как ни в чём не бывало.

S>В взрослых проектах выгодней один раз заморочиться с API


Ну вот в стандартной библиотеке классов заморочились с `Try*(out)`, а во Framework Design Guidelines позже написали: «X AVOID using out or ref parameters... The out parameters can be seen as extra return values, and grouping them together makes the method signature easier to understand.»
Глаза у меня добрые, но рубашка — смирительная!
Re[8]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 20.07.16 09:05
Оценка: :)
Здравствуйте, HeBpuMHeCkaTuHa, Вы писали:


HBM>Если Pipe Operator появится, это будет мега круто.

+1

HBM>Что до "элвис-оператора", то это просто синтаксический сахар и костыль из-за отсутствия Options Type.

По кругу ходим. По мне, так это option — костыль из-за неумения большинства языков в not-null-references. Последние планируются в восьмом шарпе, не так долго ждать.
Отредактировано 20.07.2016 9:05 Sinix . Предыдущая версия .
Re[5]: [Ann] .Net Core roadmap
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.07.16 13:04
Оценка: :)
Здравствуйте, Sinix, Вы писали:

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


S>>>Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.


S>>В VS 2015 апдейт 3 появилась возможность создавать библиотеки и приложения под .Net Core

S>Сказано же, rc. Релиз осенью, вместе с поддержкой csproj.

И сейчас есть поддержка csproj. Просто несколько другая структура проекта.


Ну пока выйдет релиз думаю прикрутить методы расширения.
Можно к каждому типу прикрутить типы реализующих расширения.
Поиск провести по типу и сборкам. Может есть какие то другие решения?
и солнце б утром не вставало, когда бы не было меня
Re: [Ann] .Net Core roadmap
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.07.16 09:16
Оценка:
Здравствуйте, Sinix, Вы писали:

Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2
В проекте при указании типа проекта портативный.
Если поставить .NetStandart1.5 ругается на ошибки Object неопределен.

Когда .Net Core будет соответствовать .NetStandart1.6, или что нужно сделать, что бы студия понимала .NetStandart1.5, так как .Net 4.6.2 не нужен.
и солнце б утром не вставало, когда бы не было меня
Re[8]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 12:20
Оценка:
Здравствуйте, Jack128, Вы писали:

J>не, те хочется сразу по переменным разложить parsed, то по идее, что то такое должно сработать:

Ну вот и попробуй объяснить любому нормальному девелоперу (это которому ехать, а не шашечки), что такой вариант правильный и что отныне надо использовать только его. Я ж говорю — съедят

J>Ну из твоих примеров, я вижу, что лучший вариант, использование Nullable + допилить PM, чтоб это был PM, а не тупой typetest.

Угу, именно к этой мысли и пытался подвести. Большая часть инженерии заключается в умении _не_ использовать инструмент там, где он не нужен.

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


J>А на счет out var, если я правильно понял, то if (int.TryParse(str, out var value) {} — value видно только внутри скобок

J>Тогда такой код:... будет в пролете. Если так, то уж совсем криво этот синтаксис выглядит.

Как раз из-за вот этого момента out var и не попали в c#6, насколько помню.

Правильный вариант обсуждается до сих пор и главный аргумент за текущее поведение — схожесть с pattern matching:

The reason for this rule is that we expect people to often write code like

if (o is FooNode node && node.Whatever) { ... code using node ... } else
if (Something && o is BarNode node) { ... code using node ... } else
if (o is BazNode node) { ... code using node ... }


and we don't want to force them to have to think up new names for every node. ...
Also we don't want different but overlapping scoping rules for pattern variables and these "out" variables.

Re: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 20:04
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Bring functional programming concepts to .NET languages

S>* Tuples
S>* Pattern matching

Бебилы ...! (ц)

Ни для того, ни для другого поддержка в рантайме не нужна. А вот для замыканий — нужна. И для алгебраических типов-значений (т.е. вэлью-типов с переменным типом) нужна.

Когда же в МС в команду дотнета возьмут тех кто разбирается в ФП?

S>Performance and Code Quality

S>* Value Tasks

А это что?

S>* Throw expressions


А это?

S>* Binary literals


И тут не очень ясно о чем речь.

S>* Digit separators


Это только к Шарпу отношение имеет. Причем тут донтет?

S>Developer Productivity

S>* Out vars
S>* Local functions
S>[/q]

Давно пора, но это опять же фича конкретного языка. В Немерле и ФШарпе она есть от рождения.

S>Нужное выделил ссылкой. Забавно всё-таки, фича сначала не попала в релиз c# 6, затем попала в планы на c# 8, затем внезапно переехала в седьмой шарп.


Тормозят они, похоже. Очень экстенсивная разработка у них.

S>Ну и чтоб два раза не вставать: c# 7 work list of features опять обновили, теперь в нём помимо pattern matching акцент на кодогенерацию. Ох уж эти сказочники...


Да, уж.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 18.07.16 20:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Бебилы ...! (ц)

VD>Ни для того, ни для другого поддержка в рантайме не нужна.

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

VD>А это что?

Не-не-не, я уже наспорился на тему "шарп отстой, потому что не как в N" Если у кого есть желание объяснять — велкам
Re[9]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 21:05
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Угу, именно к этой мысли и пытался подвести. Большая часть инженерии заключается в умении _не_ использовать инструмент там, где он не нужен.


S>Когда про это забывают, как раз и получаются предложения-кадавры, которые удобны только для очень частных случаев.


Я подобное обоснование часто вижу от тех, кто реальных аргументов найти не может. Мол люди тупые будут выбирать не подходящие фичи в неподходящих случаях. Причем все кто это говорит они то так точно не сделают.

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

Например, у option может быть метод Iter или Do с которым код будет выглядеть так:
TryParse(text).Do(WriteLine);

и Map / Select для того самого пробрасывания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.07.16 21:16
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Ну блииин, для таких набросов у нас есть специально обученные люди, не надо у них хлеб отбивать

S>В рантайме правок нет. Речь про правки в компиляторах, они входят в состав тулинга, поэтому и упомянуты как часть roadmap.

Тогда им нужно отделять фичи языка, а от фич дотнета. А то они явно валят все в одну кучу.

S>Не-не-не, я уже наспорился на тему "шарп отстой, потому что не как в N" Если у кого есть желание объяснять — велкам


До тех пор пока N не стал поддерживаться МС тут многие предпочли бы чтобы хорошие фичи N (а плохих там мало) по быстрее перекачевывали бы в Шарп.

ПМ — это самая ожидаемая фича, думаю. А кортежи они как бы являются неотемлемым приложением.

Собственно некоторые решения в Шарпе лично мне нравятся. Те же именованные кортежи (с именованными полями) или возможность расширять ПМ за счет is-операторов, например.

Кстати, конверсия реф/аут-параметров в кортеж — это фича F#-а, а не N. Как видишь, тут народ не держится за N или Х. Людям просто искренне желают чтобы Шарп стал лучше.

В дизайне Шарпа наделано уже не мало косяков. И их дальнейшее увеличение никого не радует.

По мне фича с объявлением переменных в аут-параметре тоже вполне ничего и проблему решает. Но подход с преобразованием в кортеж красивее. Особенно он красивее в местах где можно этот кортеж передать. При этом компилятор сам переложит данные в кортеж, а у нас будет красивый код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Дурак всегда найдет, где лоб разбить
От: Qbit86 Кипр
Дата: 19.07.16 00:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я подобное обоснование часто вижу от тех, кто реальных аргументов найти не может.

VD>В реальности дурак он всегда найдет где лоб разбить, а нормальный всегда выберет что удобнее.

В свою очередь, такую аргументацию можно встретить от адептов C++. Мол, это не язык небезопасный; просто дурак всегда найдёт, как выстреилть в ногу :)
Глаза у меня добрые, но рубашка — смирительная!
Re[8]: Grouping them together
От: Sinix  
Дата: 19.07.16 03:13
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Вариант с `Try*(out)` не обязывает пользователя делать проверку. При отстутсвии проверки в этом случае всё будет хуже: вместо сообщения о разыменовании пустого опциона, пользователь продолжит работать с дефолтным значением как ни в чём не бывало.


и с введением not null references необходимость в Option отпадёт окончательно

;P

Скажем так: я имел возможность поработать с проектом, в котором что-то типа Option было введено с самого начала и использовалось по всему коду. Вот с тех пор я что-то уверен, что все агитаторы за Option в текущем шарпе сами их ни разу в реальных проектах не использовали. Если коротко — это просто убого, ближайшая аналогия — возврат к рукопашной проверке и протаскиванию error codes вместо исключений.

Q>Ну вот в стандартной библиотеке классов заморочились с `Try*(out)`, а во Framework Design Guidelines позже написали: «X AVOID using out or ref parameters... The out parameters can be seen as extra return values, and grouping them together makes the method signature easier to understand.»


Ну а первую заповедь FDG, которая

Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios

кто будет помнить?

Если 99% сценариев использования заключается в if (TryGet(out var x) { ... }, зачем городить if (TryGet() is Some(var x)) { ... } по всему коду?

Тоже будешь рассказывать про "фича удобная, это программисты до неё не доросли"?
Re[4]: [Ann] .Net Core roadmap
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.07.16 07:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>До тех пор пока N не стал поддерживаться МС тут многие предпочли бы чтобы хорошие фичи N (а плохих там мало) по быстрее перекачевывали бы в Шарп.


А что N MS уже в VS встраивает? Что то я не видел при инсталяции предложения поставить N
и солнце б утром не вставало, когда бы не было меня
Re[8]: [Ann] .Net Core roadmap
От: boyarin  
Дата: 19.07.16 19:37
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Кортеж и ПМ — это более универсальное решение не требующее костылей вроде этого. Оно заставляет проверить наличие значения перед его использованием и сокращает количество сущностей которые нужно контролировать.



В случае с TryParse().Do() как потом удобно контролировать что это Do было выполнено?
А допустим если TryParse(ICollection).Do() как удобно проконтролировать что выполнено N раз?
Re[9]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.07.16 20:39
Оценка:
Здравствуйте, boyarin, Вы писали:

B>В случае с TryParse().Do() как потом удобно контролировать что это Do было выполнено?


Оно будет выполнено, если результат Some() и не будет, если None(). Контролировать тут нечего. Это все равно, что if.

B>А допустим если TryParse(ICollection).Do() как удобно проконтролировать что выполнено N раз?


option это не коллекция. Это обертка для результата. В ней всегда "один элемент", так как на список она лишь похожа, но по факту списком не является.

Смотри https://en.wikipedia.org/wiki/Option_type
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Ann] .Net Core roadmap
От: boyarin  
Дата: 19.07.16 21:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Оно будет выполнено, если результат Some() и не будет, если None(). Контролировать тут нечего. Это все равно, что if.


Имеется в виду что в дальнейшейм в коде надо сделать то или иное действие над результатами в зависимости от того был ли выполнен Do(someaction) и если был то сколько раз. 0,1,Many.

VD>option это не коллекция.


Вопрос был есть ли вариант работы с коллекциями, если да то какой.
Re[11]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.07.16 23:32
Оценка:
Здравствуйте, boyarin, Вы писали:

B>Имеется в виду что в дальнейшейм в коде надо сделать то или иное действие над результатами в зависимости от того был ли выполнен Do(someaction) и если был то сколько раз. 0,1,Many.


Do — это для выполнения императивных действий не предпологающих результата.

Если нужно произвести обработку независимо от того есть значения или нет используется метод Map/Select:
var optionalResult = int.TryParse(text).Select(res => что-то делаем со значением);

При этом лямбда вызовется только если TryParse вернул значение. Результат Select-а так же заворачивается в option.

В общем, как со списками. По сути, option можно рассматривать как список из одного элемента. Только малость по эффективнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [Ann] .Net Core roadmap
От: gbear Россия  
Дата: 20.07.16 06:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Те же именованные кортежи (с именованными полями) ...


Вещь, на мой подпорченный ФП вкус, весьма и весьма спорная. Вся (пусть даже и гипотетическая — типа "структурная" типизация для "record'ов" — круто же) ценность которой полностью нивелируется доведенным до ума ПМ... чего, как раз, и не наблюдается. К сожалению.

А если речь не о "структурной" типизации таких "кортежей", то вообще не ясно зачем _это_ называть _кортежем_?! Record'ы — они и в Африке record'ы
Re[12]: [Ann] .Net Core roadmap
От: boyarin  
Дата: 20.07.16 09:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Do — это для выполнения императивных действий не предпологающих результата.


Императивность и наличие результата никак не связанные поняти.

VD>В общем, как со списками. По сути, option можно рассматривать как список из одного элемента. Только малость по эффективнее.


Пример неудачный. Все что ты привел решается с помощью Linq, Extension methods и элвис-оператора.
Re[5]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.16 13:15
Оценка:
Здравствуйте, gbear, Вы писали:

G>Вещь, на мой подпорченный ФП вкус, весьма и весьма спорная. Вся (пусть даже и гипотетическая — типа "структурная" типизация для "record'ов" — круто же) ценность которой полностью нивелируется доведенным до ума ПМ... чего, как раз, и не наблюдается. К сожалению.


Ага. Очень точно подмечено. На "подпорченный ФП вкус".

На самом деле имена — это очень полезно. Снимает проблемы и дает возможности для интеллисенса.

G>А если речь не о "структурной" типизации таких "кортежей", то вообще не ясно зачем _это_ называть _кортежем_?! Record'ы — они и в Африке record'ы


Записи (рекорды) они тоже структурно типизированы в большинстве ФЯ. И по сути — это и есть записи. Просто в МС жопа с терминалогией. Они все перековеркали. Там реальных ФП-шников с научным бэкграундом в команде шарпа, похоже, очень мало.

Но не суть. Записи они обратно совместимы с кортежами. Так что рекорд — это улучшенный кортеж. Хуже от него точно не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.07.16 13:37
Оценка:
Здравствуйте, boyarin, Вы писали:

B>Императивность и наличие результата никак не связанные поняти.


Учи матчасть. Императив — это действие (приказ). Императивный код подразумевает изменение состояние, что выливается в то, что ничего возвращать не надо. Если же у тебя код что-то возвращает без побочных эффектов, то это функциональный код.

VD>>В общем, как со списками. По сути, option можно рассматривать как список из одного элемента. Только малость по эффективнее.


B>Пример неудачный. Все что ты привел решается с помощью Linq, Extension methods и элвис-оператора.


Ага. Если у тебя в руках молоток, то все вокруг кажется гвоздями. (ц)

Методы расширения — это конечно механизм которым многое можно добавить сбоку. В том числе и методы Do/Iter и Map/Select. Но option — это отдельный паттерн. К линку он не имеет отношения. Просто его можно интерпретировать и как список из одного элемента.

Главная же задача option-а — хранение/обраобтка понятия "отсутствует значение". option — это, можно сказать, правильно спроектированный Nulable<T>.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [Ann] .Net Core roadmap
От: gbear Россия  
Дата: 21.07.16 18:45
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>На самом деле имена — это очень полезно. Снимает проблемы и дает возможности для интеллисенса.

Пока — судя по тому что я читал... да хоть тот же proposal — что-то не сильно похоже Да один splatting чего только стоит
А вот ПМ нормальный, как раз "проблемы" снимает... и "возможностей для интеллисенса" дает ничуть не меньше. Если не больше.

VD>Записи (рекорды) они тоже структурно типизированы в большинстве ФЯ.

Вот только C# к этим ФЯ не относится.

VD>И по сути — это и есть записи. Просто в МС жопа с терминалогией. Они все перековеркали. Там реальных ФП-шников с научным бэкграундом в команде шарпа, похоже, очень мало.

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

VD>Но не суть. Записи они обратно совместимы с кортежами.

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

VD>Так что рекорд — это улучшенный кортеж. Хуже от него точно не будет.

Ой ли... Таки повторю свой поинт — нормальный ПМ снимает все проблемы с "именованием" кортежей:

public (int, int) Tally(IEnumerable<int> values) 
{
...
}

...
{
  // Как нам нравится, так и матчим
  (var sum, var count) = Tally(myValues); // Хотим так...
  (int s, int c) x = Tally(myValues) // А можем и так
  (long y, long) z = Tally(myValues); // Если кортежи не инварианты (вот честно не помню, как с этим в C#), то можно и так. Если надо.
}


И никаких тебе проблем. Кортежи, остаются кортежами. Нужны тебе имена — пожалуйста... такие, какие хотишь. Ровно тоже самое можно использовать и при объявлении ф-ции/лямбды, которая "принимает" кортеж.
Re[3]: [Ann] .Net Core roadmap
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.07.16 07:19
Оценка:
Здравствуйте, Sinix, Вы писали:

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


S>>Кстати сейчас .Net Core не соответствует стандарту .NetStandart1.6. .NetStandart1.5 в студии ругается, на то, что нужен .Net 4.6.2

S>Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.

В VS 2015 апдейт 3 появилась возможность создавать библиотеки и приложения под .Net Core
Вкладка
Шаблоны->Windows->.Net Core

Такой проект отличается от портативного и есть поддержка .NetStandart1.6.
Правда правда при установке Newtonsoft.Json.NetCore говорит, что все прекрасно, но при компиляции говорит что не может найти зависимости.
И пришлось вручную добавлять Newtonsoft.Json.NetCore.dll и System.Runtime.Serialization.Primitives.dll нужной версии


Про установку SDK и прочее можно посмотреть здесь
http://metanit.com/sharp/aspnet5/1.2.php
и солнце б утром не вставало, когда бы не было меня
Re[7]: [Ann] .Net Core roadmap
От: _NN_ www.nemerleweb.com
Дата: 27.07.16 09:41
Оценка:
Здравствуйте, gbear, Вы писали:

G>
G>public (int, int) Tally(IEnumerable<int> values) 
G>{
G>...
G>}

G>...
G>{
G>  // Как нам нравится, так и матчим
G>  (var sum, var count) = Tally(myValues); // Хотим так...
G>  (int s, int c) x = Tally(myValues) // А можем и так
G>  (long y, long) z = Tally(myValues); // Если кортежи не инварианты (вот честно не помню, как с этим в C#), то можно и так. Если надо.
G>}
G>


По опыту могу сказать, что публичные функции такого вида очень запутывают чтение кода.
Даже кортежи не нужны:
Pair<int, int> F();

// vs.

class Data { int Width; int Height; }
Data F();


Во втором варианте явно видно, что возвращается.

Было бы полезно иметь именованные кортежи вроде:

public (int Sum, int Count) Tally(IEnumerable<int> values) 
{
...
}

...
{
  // Как нам нравится, так и матчим
  (var sum, var count) = Tally(myValues); // Хотим так...
  (int s, int c) x = Tally(myValues) // А можем и так
  (long y, long) z = Tally(myValues); // Если кортежи не инварианты (вот честно не помню, как с этим в C#), то можно и так. Если надо.
}
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: [Ann] .Net Core roadmap
От: Sinix  
Дата: 27.07.16 11:14
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>Дык .NET Core Tooling всё ещё RC, релиз осенью будет. Если опять ничего внезапно(tm) не вылезет.


S>В VS 2015 апдейт 3 появилась возможность создавать библиотеки и приложения под .Net Core

Сказано же, rc. Релиз осенью, вместе с поддержкой csproj.
Re[7]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.16 13:46
Оценка:
Здравствуйте, gbear, Вы писали:

G>Пока — судя по тому что я читал... да хоть тот же proposal — что-то не сильно похоже Да один splatting чего только стоит


Что за splatting?

G>А вот ПМ нормальный, как раз "проблемы" снимает... и "возможностей для интеллисенса" дает ничуть не меньше. Если не больше.


ПМ — это хорошо, но проблем, вызванных тем что в кортежах отсутствуют имена, он никак не решает. Имена переменных, при декомпозиции кортежей, придется задавать вручную.
Интеллисенс тут ничем не поможет. А вот если имена будут, то IDE сможет сделать имена для переменны в автомате.

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

VD>>Записи (рекорды) они тоже структурно типизированы в большинстве ФЯ.

G> Вот только C# к этим ФЯ не относится.

С тех пор как в шарпе пеоявились лямбды — имеет. Сказав А (начав движение в сторону ФЯ) надо говорить и Б (добавлять фичи нужные для удобного программирования в функциональном стиле).

G>Ну, всё таки парни там не настаивают сильно на номинативной типизации таких "кортежей". С другой стороны, когда я это читаю, у меня создается стойкое ощущение... легкого недоумения — они это серьезно?!


Предложение по "кортежам" есть. О чем ты говоришь я не знаю.

VD>>Так что рекорд — это улучшенный кортеж. Хуже от него точно не будет.

G>Ой ли... Таки повторю свой поинт — нормальный ПМ снимает все проблемы с "именованием" кортежей:

G>
G>public (int, int) Tally(IEnumerable<int> values) 
G>...
G>  (var sum, var count) = Tally(myValues); // Хотим так...
G>  (int s, int c) x = Tally(myValues) // А можем и так
G>


А можно и так:
(var count, var sum) = Tally(myValues); // Все перепутали, но кто же нас проверит?!

Или так:
(var x, var age) = Tally(myValues); // Все перепутали, но кто же нас проверит?!


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

Согласен, что и кортежи — это уже хорошо. Но если он придумали как сделать записи, то это еще лучше.

Не стоит биться с ветряными мельницами. Лучше — не хуже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.16 13:47
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>По опыту могу сказать, что публичные функции такого вида очень запутывают чтение кода.


Не скажу, что прямо таки запутывает, но имена, несомненно, лучше. Тут даже обсуждать нечего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.16 13:49
Оценка:
Здравствуйте, Sinix, Вы писали:

S>вместе с поддержкой csproj.


Мне вот интересно, как работает мозг тех кто начинает изобретать велосипед на ровном месте. Вот зачем было придумывать свой (кор цлр-ный) тип проектов? Почему сразу было не взять МСБилдный?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [Ann] .Net Core roadmap
От: gbear Россия  
Дата: 28.07.16 05:35
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>По опыту могу сказать, что публичные функции такого вида очень запутывают чтение кода.


По своему опыту, могу только возразить, что "публичные функции такого вида" вообще никак не сказываются на чтении кода. Ровно как и любые другие ф-ции, которые возвращают "контейнер"... будь то массив, список или даже какой-нибудь IEnumerable. "Очень запутывают чтение кода" выражения типа
a.Item1.Item3.Item2.Item5

, а не ф-ции, возвращающие кортежи. Вот, в первую очередь, такого рода конструкции и надо "выпиливать".

_NN>Во втором варианте явно видно, что возвращается.

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

А если же речь таки о номинативной типизации, то нужно просто перестать называть это "кортежами". Люди пугаются же
Re[8]: [Ann] .Net Core roadmap
От: gbear Россия  
Дата: 28.07.16 06:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что за splatting?


var t = (int a, int b) => new (int x, int y) {x = a, y = b};
t(t(1,2)); // splatting;


VD>ПМ — это хорошо, но проблем, вызванных тем что в кортежах отсутствуют имена, он никак не решает.

Мы же прекрасно понимаем, что у элементов кортежа нет имен просто в силу их (кортежей) принципиальной структурной типизации. При номинативной типизации — это будут уже не кортежи, а рекорды.

VD>Имена переменных, при декомпозиции кортежей, придется задавать вручную.

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

VD>Интеллисенс тут ничем не поможет. А вот если имена будут, то IDE сможет сделать имена для переменны в автомате.

Для того, чтобы IDE могла "сделать имена для переменных в автомате" — вообще не обязательно эти самые имена тащить в систему типов.

VD>В общем, на мой взгляд, очевидно, что от именованных кортежей ака записей польза есть.

Вот и ты туда же... как и авторы "предложения" Ну, или либо чего-то не понимаю.

"Рекорды"... по крайней мере, то, что под этим понимают канонически:

var (int a, int b) A;
var (int x, int y) B;


Тип у A и B — _разный_ — и это важно. В этом — номинативной типизации — основной смысл "рекордов".

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

VD>>>Записи (рекорды) они тоже структурно типизированы в большинстве ФЯ.

G>> Вот только C# к этим ФЯ не относится.
VD>С тех пор как в шарпе пеоявились лямбды — имеет. Сказав А (начав движение в сторону ФЯ) надо говорить и Б (добавлять фичи нужные для удобного программирования в функциональном стиле).
"Да_ладно.жпг". Я, правда, дааавненько ничем серьезным на C# не страдал... но, сдается мне, делегаты и до лямбд структурно типизировались. И совсем не понятно, причем тут типизация лямбд, если в топике речь о несколько другом?

G>>Ну, всё таки парни там не настаивают сильно на номинативной типизации таких "кортежей". С другой стороны, когда я это читаю, у меня создается стойкое ощущение... легкого недоумения — они это серьезно?!

VD>Предложение по "кортежам" есть. О чем ты говоришь я не знаю.
Возможно я смотрел "не на тех дроидов", но вот, например, это:

public (int sum, int count) Tally(IEnumerable<int> values) 
{
  ...
}

...

(double sum, long count) weaken = Tally(...); // why not?
(int s, int c) rename = Tally(...) // why not?


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


VD>А можно и так:

VD>
VD>(var count, var sum) = Tally(myValues); // Все перепутали, но кто же нас проверит?!
VD>


VD>Или так:

VD>
VD>(var x, var age) = Tally(myValues); // Все перепутали, но кто же нас проверит?!
VD>


?! Если вопрос таки только в этом, то совсем не понятно зачем эту "проблему" решать таким извращенным способом?! Можно подумать, что кто-то вдруг взял — и запретил метаданные в .NET

VD>Вот если бы имена были, то ошибку хотя бы можно было бы выявить.

Начинать надо, наверное с того, что вообще не факт что это "ошибка". Если это таки ошибка, то, я извиняюсь, какого рода?


VD>Да и декомпозиция она ведь место и силы отнимает. Во многих случаях обратиться к полю по имени будет проще.

Вот как раз опыт использования ФЯ богатых на кортежи, показывает, что в большинстве случаев полная структура тебе практически никогда не нужна... ты можешь даже и не иметь представления о ней. Сматчил нужное — остальное в dev\null... даже, когда речь идет всего лишь об одном единственном элементе кортежа.

VD>Не стоит биться с ветряными мельницами. Лучше — не хуже.

Я — глядя на это — не сильно уверен что "это" — таки "лучше".
Re[9]: [Ann] .Net Core roadmap
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.07.16 20:01
Оценка:
Здравствуйте, gbear, Вы писали:

G>
G>var t = (int a, int b) => new (int x, int y) {x = a, y = b};
G>t(t(1,2)); // splatting;
G>


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

Кстати, на практике вещь практически не нужная. Немерл ее поддерживат, но желания применять особо нет.

А вот в типизаторе это проблем создает.


VD>>ПМ — это хорошо, но проблем, вызванных тем что в кортежах отсутствуют имена, он никак не решает.

G>Мы же прекрасно понимаем, что у элементов кортежа нет имен просто в силу их (кортежей) принципиальной структурной типизации. При номинативной типизации — это будут уже не кортежи, а рекорды.

Я не знаю что вы там понимаете. Я вижу, что можно сделать именованные поля. Кортежем это, правда, называть будет некорректно. Но мне нужны не шашечки, а ехать.


VD>>Имена переменных, при декомпозиции кортежей, придется задавать вручную.

G>Кхм... как бы это вообще нормально,

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

G>что "проблема" интерпретации данных, типизированных структурно, она на стороне интерпретатора целиком.


Если проблем есть, то ее лучше решать, а не перекладывать на других. Вот если ее нельзя решить, то другое дело. Но тут то можно!

G>Что тут такого-то? В противном случае, мы меняем кортежи на рекорды.


Меняем. МС и предлагает создать рекорды. Просто по глупости их кортежами назвал.

В СБУД вот вообще нет кортежей. Там именно что записи. И все довольны. И никому не мешает, что в реляционной теории, на которой они основаны, используются кортежи.

Запись она вполне себе применима вместо кортежа.

VD>>Интеллисенс тут ничем не поможет. А вот если имена будут, то IDE сможет сделать имена для переменны в автомате.

G>Для того, чтобы IDE могла "сделать имена для переменных в автомате" — вообще не обязательно эти самые имена тащить в систему типов.

А куда их тащить?

VD>>В общем, на мой взгляд, очевидно, что от именованных кортежей ака записей польза есть.

G>Вот и ты туда же... как и авторы "предложения" Ну, или либо чего-то не понимаю.

Тут оно как. Может я чего не понимаю. А может ты.

G>"Рекорды"... по крайней мере, то, что под этим понимают канонически:


G>
G>var (int a, int b) A;
G>var (int x, int y) B;
G>


Синтаксис какой-то непонятный. Зачем тут "var"?

G>Тип у A и B — _разный_ — и это важно.


Еще бы понять как ты себе свои гипотетические примеры понимаешь. Если А и B — это именованные типы, а не переменные — то не нужно.

Если речь идет о совпадении имен у полей, то в принципе это полезно.

G>В этом — номинативной типизации — основной смысл "рекордов".


Похоже, ты не правильно понимаешь термин "номинативная типизация". Наминативная типизация — это когда:
class A
{
  publib int X;
}

и
class B
{
  publib int X;
}

это разные типы только лишь на том основании, что у них разные имена.

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

И такое более строгое определение структуры — полезно. Причем полезно не для теоретиков, а для практиков. Банально будет меньше ошибок и можно будет не заниматься декомпозицией, когда нужно одно поле из 10.

G>Если тоже самое предполагается для "именованных кортежей", то надо просто перестать их называть _кортежами_.


Я не знаю, что такое "именованные кортежи".

G>Если же для них тип А и тип В будет совпадать, то — кроме потенциальных проблем, с очевидной локальностью таких типов — непонятно, а "зачем вообще козе такой баян" на уровне _системы типов_? Чего мы получаем-то, спуская это на такой уровень? Разве нельзя добиться ровно того же, не затрагивая систему типов вообще?


Ты явно запутался в понятии структурной типизации. Включать в структуру имена поле ни разу не проблема.

G>"Да_ладно.жпг". Я, правда, дааавненько ничем серьезным на C# не страдал... но, сдается мне, делегаты и до лямбд структурно типизировались. И совсем не понятно, причем тут типизация лямбд, если в топике речь о несколько другом?


Ну, не понял, значит не понял. Я вряд ли могу помочь. Хочешь еще раз повторю, что с появлением лмябд Шарп сделал шаг к ФП. Теперь на нем можно программировать в ФП стиле, но есть проблемы. И раз шаг к ФП сделан, то надо идти дальше упрощая людям жизнь.

G>Возможно я смотрел "не на тех дроидов", но вот, например, это:


G>в моем представлении, имеет не много общего с номинативной типизацией. Из предложения вообще, имхо, местами весьма трудно понять "чего таки хотим"... какую такую "проблему" решаем


У меня не возникает вопросов какие они проблемы решают. При этом я даже на их объяснения не смотрел.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [Ann] .Net Core roadmap
От: ionoy Эстония www.ammyui.com
Дата: 29.07.16 07:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>>вместе с поддержкой csproj.


VD>Мне вот интересно, как работает мозг тех кто начинает изобретать велосипед на ровном месте. Вот зачем было придумывать свой (кор цлр-ный) тип проектов? Почему сразу было не взять МСБилдный?


Насколько я понимаю, первоначально Core разрабатывался как веб платформа (Project K?), поэтому старались угодить соответствующим разработчикам.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[10]: [Ann] .Net Core roadmap
От: gbear Россия  
Дата: 29.07.16 07:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Пример, конечно, потрясающий. Верхний набор букв к шарпу не откносится. Но идея ясна. Никогда не знал, что передача кортежа в фукнцию так мудрено называется.


Примут эти "кортежи" в том виде, что предлагается — будет относится

VD>А вот в типизаторе это проблем создает.

Блин... о чем и речь!

VD>Меняем. МС и предлагает создать рекорды. Просто по глупости их кортежами назвал.

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

Ограничусь лишь вот этим:

G>>Для того, чтобы IDE могла "сделать имена для переменных в автомате" — вообще не обязательно эти самые имена тащить в систему типов.

VD>А куда их тащить?

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