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[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[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...
Пока на собственное сообщение не было ответов, его можно удалить.