Re[13]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.14 16:34
Оценка:
Здравствуйте, KRT, Вы писали:

KRT>Если речь идет об обычных приложениях (не метро), то можно открыть папку. Правый клик по приложению > Открыть расположение файла


Как я понимаю, расположение файла — это не то. Если у меня шорткат, то "расположение файла" приведет меня в папку где находится файл на который ссылается шорткат. А мне нужно в папку где лежит шорткат.

Да и вообще — это не правильно, что исчезла привычная и удобная функциональность. А ведь куча продуктов рассчитывает на нее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Ann] VS14 Сtp0
От: fddima  
Дата: 24.06.14 22:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В немерле вообще нет Extract Method. Не было кому запилить. Но тот же рефакторинг переименования работает и внутри сплайсов. Extract Method просто запретить работать в условиях когда выделение пересекает границы сплайсов. Допускать рефакторинг только внутри одного сплайса или вне $-строки.

+1. Я не так давно начал пользовать extract method очень по чуть-чуть (скорее ради интереса). Оно вроде и удобно, но честно говоря с помощью copy-paste можно добиться того же самого, за тоже самое время — один фиг потом нужно причесывать метод. Поэтому — лично моё мнение — нет — и не надо. Самый главный рефакторинг который вообще существует — это rename всего чего угодно. Остальное — иногда полезно и весьма на любителя. И уж точно если сначала думать а потом писать — extract method и подобное — глупости. Иначе говоря — на мой взгляд — фича ради фичи.
Re[20]: [Ann] VS14 Сtp0
От: fddima  
Дата: 24.06.14 22:59
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Я бы сказал, что спецификация довольно спорная. Оставляет возможность для нелепых ошибок. Единственный разумный аргумент за нее — производительность. Рантайм-проверки энумов были бы дороким удовольствием.

Нет, не спорная. Она именно такая, которая нужна. Это теоретикам, видимо, навроде тебя она кажется спорной.
Поведение enum — как минимум наследуется от прародителей.
Кроме того, enum handling в WCF — отвратительно отвратительный (!!!). А именно до безобразия строгий. Оно видители не может принять то, что не задекларировано. Мы пытались на основе WCF реализовать действующий протокол — и это местами enum — не то что было проблемой, просто выглядело глупым. Сейчас спецификация объявляет флаговое поле с такими значениями, потом их добавляет. Но это никак не значит, что клиент (т.е. мы), обязаны их обрабатывать — всё что мы обязаны — это их хранить. И неизвестные флаги — не повод отвергать входящее сообщение. Это всё в противовес этой "нелогичности".
Нелогично — это использовать enum-ы так, как они не использовались до этого.
Поэтому все эти теоретизации — это глупость. enum — был и есть одним из надвидов из основных примитивных типов — почему бы ему таким и не быть.
Если очень такого хочется — то наверное нужно сделать другой тип. Почему бы нет? Хотя решения приведенной проблемы — тысяча. Только они никак не помогут тому, что код всё равно должен быть "bullet-proof". А именно — если он анализирует enum — то должен покрывать все случаи. Если это флаги — то и компилятор то по факту никак не поможет (флаги и их возможные и допустимые варианты — для компилятора — загадка).
Re[6]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 25.06.14 01:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как я понял даже при включении эксперементальных фич их понимает только компилятор. Почему их не понимает лэнгвидж-сервис? Как я понял весь смысл Рослина в том, что он переиспользует и для компилятора, и для лэнгвидж-сервиса один и тот же код. Я что-то не так понял?


Действительно, и в компиляторе, и в language service для базовой поддержки языковых фич (т.е. не считая специальные возможности в intellisense, рефакторингах и т.д.) должен работать один и тот же код (те же самые методы в тех же сборках) — одна и та же логика не должна быть реализована в разных местах. Но теоретически можно подсунуть разные версии сборок для компилятора и для language service. Но если такое происходит в CTP — то это странный баг. Я не наблюдаю этого на последних ночных билдах, установленных на моей машине. Попробую разобраться, что там происходит в CTP...
Re[20]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 25.06.14 01:06
Оценка: 7 (1)
Здравствуйте, VladD2, Вы писали:

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


Работа ведётся, уже довольно давно. Возможно, вскоре появится прототип в open репозитории.
Re[10]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 25.06.14 01:24
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Ты думаешь, это единственная фича, которой мы занимаемся? Или это самая важная фича в языке?


VD>Не думаю. Но прошло уже 5 лет как пилится Рослин (я не ошибаюсь?). Можно было такую мелочь и реализовать. Фича мелкая, но очень удобная. Плюс вау-эффект. Учитывая, что ты сам говоришь, что работы велись, не ясно что могло привести к решению их остановить.


То, что есть более приоритетные мелочи. Есть баги, которые необходимо пофиксить. Есть перформанс проблемы, которые надо решать. Есть огромная работа по переводу всей студийной функциональности на Roslyn. Есть новые студийные фичи, которые требуют определённых API со стороны Roslyn.

VD>Но судя по тому что вы и свою реализацию выкинули вряд ли на это можно надеяться.


Мы ничего не выкидывали. Есть неоконченый дизайн и прототип, который совершенно не production quality.

VD>Что до решений, то решения всегда принимает один человек. Коллективное принятие решений не бывает.


Language design team принимает решения коллегиально. Я не знаю случая, когда дизайнеры расходились по каким-то вопросам, и вместо урегулирования этих вопросов кто-то один в приказном порядке зафиксировал какое-то решение.

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


Спасибо, идеи очень хорошие, мы постараемся их учесть. Но они ещё раз демонстрируют, что дизайн этой фичи не является однозначным и тривиальным.
Re[10]: [Ann] VS14 Сtp0
От: _NN_ www.nemerleweb.com
Дата: 25.06.14 09:10
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


_NN>>Так ведь сделали ключиком


VD>Я говорил о том, что можно было бы сделать ключ конкретно для этой фичи.


Имеется ввиду официальная опция в проекте и официальный ключ компилятора ?
В таком случае конечно только за.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[11]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.14 10:07
Оценка:
Здравствуйте, nikov, Вы писали:

N>Мы ничего не выкидывали. Есть неоконченый дизайн и прототип, который совершенно не production quality.


А на него можно как-то посмотреть?

N>Спасибо, идеи очень хорошие, мы постараемся их учесть. Но они ещё раз демонстрируют, что дизайн этой фичи не является однозначным и тривиальным.


Никакой дизайн не является однозначным. На то он и дизайн. Все можно сделать по разному.

В данном случае не нужно изобретать велосипед. Нужно просто воспользоваться чужим опытом. Ну, и не делать вселенский всемогутер, как тут некоторые предлагают.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.06.14 08:21
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Нормальнй скайп днем с огнем пришлось выискивать. Еле нашел.


Где ты искал то? Потому что на skype.com жмем кнопку Get Skype и попадаем сразу на страницук Skype for Windows desktop.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[7]: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.06.14 08:22
Оценка:
Здравствуйте, nikov, Вы писали:

N>Действительно, и в компиляторе, и в language service для базовой поддержки языковых фич (т.е. не считая специальные возможности в intellisense, рефакторингах и т.д.) должен работать один и тот же код (те же самые методы в тех же сборках) — одна и та же логика не должна быть реализована в разных местах. Но теоретически можно подсунуть разные версии сборок для компилятора и для language service.


Я думаю дело не в разных сборках, а в том что LangVersion на lang service не влияет и он по прежнему работает в рамках C# 5.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[21]: [Ann] VS14 Сtp0
От: Tom Россия http://www.RSDN.ru
Дата: 26.06.14 10:03
Оценка:
N>Работа ведётся, уже довольно давно. Возможно, вскоре появится прототип в open репозитории.
Во во во, палегче!
Это смахивает на next big thing в C# языке!
Народная мудрось
всем все никому ничего(с).
Re[13]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.06.14 12:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Где ты искал то? Потому что на skype.com жмем кнопку Get Skype и попадаем сразу на страницук Skype for Windows desktop.


Возможно они что-то поменяли. Раньше чтобы найти ссылку для скачивания нужно было исакать в гугле и "Skype for Windows desktop". А что бы это сделать сначала нужно было знать что именно это нужно искать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 02.07.14 03:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Кстати, Nemerle позволяет использовать строковые литералы внутри interpolated выражений?
Re[13]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.14 16:06
Оценка: 18 (1)
Здравствуйте, nikov, Вы писали:

N>Кстати, Nemerle позволяет использовать строковые литералы внутри interpolated выражений?


Да. Но не все так просто.

Вложить в "" другую "", по понятным соображениям нельзя. У нас есть рекурсивная строка <# #>. У нее никаких проблем нет. В нее можно и "" вкладывать и саму же <# #> (так как она рекурсивна).

Вот первое попавшееся применение:
public DebugView : string
{
  get { $<#..$(Parents; "\r\n"; p => $"$p        $(p.GetType().Name)")#> }

Сплайс ..$ раскрывает список (любой энумератор). Его грамматика (в стиле найтры) такова:
syntax ListSlice = ".." "$" SliceBody;
syntax SliceBody
{
  | Identifier
  | "(" PExpr SeparatorAndConverter? ")"
}
syntax SeparatorAndConverter = ";" PExpr Converter?;
syntax Converter = ";" PExpr;


В Separator ожидается выражение возвращающее строку. Она используется как разделитель списка. По умолчанию используется ", ".
В Converter ожидается выражение функционального типа принимающего элемент списка и возвращающего строку. По умолчанию System.Convert().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 07.08.14 20:17
Оценка: 37 (3)
VD>Сейчас кода у вас есть Рослин было бы разумно начать работу над алгеброическими типами и паттерн-матчингом.

N>Работа ведётся, уже довольно давно. Возможно, вскоре появится прототип в open репозитории.


Черновик дизайна
Обсуждение на CodePlex
Публично доступного кода пока нет, ожидается через пару недель
Re[22]: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 08.08.14 08:09
Оценка:
N>Черновик дизайна
N>Обсуждение на CodePlex
N>Публично доступного кода пока нет, ожидается через пару недель

А дженерики можно будет использовать?
Re[23]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.08.14 23:15
Оценка: 30 (1)
Здравствуйте, Qodomoc, Вы писали:

Q>А дженерики можно будет использовать?


В текущем дизайне generic типы ведут себя совершенно одинаково с не-generic. Никакие сценарии для них не запрещены, но и никаких специфических возможностей (наподобие использования existential типов в pattern matching) не предусмотрено. Но если есть какие-то потребности, было бы интересно послушать. Интересует какой-то конкретный сценарий?
Re[24]: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 15.08.14 10:10
Оценка:
А что-нибудь такое можно будет:
case List<T> where T : ISmth:
Re[25]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.08.14 17:46
Оценка: 12 (1)
Здравствуйте, Qodomoc, Вы писали:

Q>А что-нибудь такое можно будет:

Q>
Q>case List<T> where T : ISmth:
Q>


Не совсем понятно по такому короткому примеру, что имеется в виду. Но я предполагаю, что раз указан констрейнт, то подразумевается, что тип-параметр T является локальным для данного кейса, но не объявлен где-то снаружи, и не участвует в типе выражения, которое мы матчим. Такой сценарий являлся бы вариантом поддержки existential типов, а это не планируется.
Re: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 19.08.14 09:08
Оценка: +1
Вышел CTP3.
Подробности здесь и здесь.

.NET Native is integrated into Visual Studio 14 for the first time with CTP 3.

Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.