Что-то в примерах ничего похожего не нашёл, а на

class Foo
{
  public MyValue : int { get; set; }
}

def f = Foo() { MyValue = 1, };

Получаю ошибки

Error: expected ';'
Error: parse error near '{...}' group: unexpected token after expression in sequence (you forget a closing bracket?).

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

_FR>Что-то в примерах ничего похожего не нашёл, а на
Используй макру Record

[Record]
class Foo
{
  public MyValue : int { get; set; }
}

def f = Foo(1);

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

_FR>>Что-то в примерах ничего похожего не нашёл, а на
WH>Используй макру Record

Спсмибо, уже нашёл

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

1. Не указывать тело у геттеров и сеттеров:

[DependencyProperty]
public SomeString : string { get; set; }

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

2. Из этого:

[DependencyProperty]
public static SomeString : string { get; set; }

Убрать из определения класса свойство, заменив его на два метода.

3. разрешить вообще не указывать акессоры, предоставив реализацию по-умолчанию, то есть что бы вылидно было следующее (аттрибут упустил):

public SomeString : string;  // => public get; public set;

public SomeString : string { private set; }; // => public get; private set;
public SomeString : string { get; }; // => public get; private set;

4. Это принципиаольно, что NemerleStudion работает с nsln и не открывает простые sln?

5. Автокомплит будет улучшаться? Сейчас приходится явно жать Ctrl+Space, а хотелось бы что бы само появлялось по нажатии точки, как в шарпе.

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

_FR>1. Не указывать тело у геттеров и сеттеров:
_FR>Сейчас генерится поле и компилятор даёт справедливый ворнинг. Хотелось бы, что бы макрос можно было писать так и что бы поле не создавалось.
_FR>2. Из этого:
_FR>Убрать из определения класса свойство, заменив его на два метода.
_FR>3. разрешить вообще не указывать акессоры, предоставив реализацию по-умолчанию, то есть что бы вылидно было следующее (аттрибут упустил):
Ща думаем как с этим бороться.

_FR>4. Это принципиаольно, что NemerleStudion работает с nsln и не открывает простые sln?
Я этим не занимался но вроде как у народа не получилось сделать по другому.

_FR>5. Автокомплит будет улучшаться? Сейчас приходится явно жать Ctrl+Space, а хотелось бы что бы само появлялось по нажатии точки, как в шарпе.
Уже. Либо собирай из исходников либо жди очережного инсталятора.

Править лучше ту версию что в репозирории. Я там успел еще фичей докрутить.

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

_FR>>1. Не указывать тело у геттеров и сеттеров:
_FR>>Сейчас генерится поле и компилятор даёт справедливый ворнинг. Хотелось бы, что бы макрос можно было писать так и что бы поле не создавалось.
_FR>>2. Из этого:
_FR>>Убрать из определения класса свойство, заменив его на два метода.
_FR>>3. разрешить вообще не указывать акессоры, предоставив реализацию по-умолчанию, то есть что бы вылидно было следующее (аттрибут упустил):
WH>Ща думаем как с этим бороться.



_FR>>4. Это принципиаольно, что NemerleStudion работает с nsln и не открывает простые sln?
WH>Я этим не занимался но вроде как у народа не получилось сделать по другому.

Но преобразование одного из другого делается простым переименованием? Сойдёт. просто у меня дома ноут слабенький, студии там нету (хотя думаю Express поставить). Но Nemerle Studio вроде как летает.

WH>Править лучше ту версию что в репозирории. Я там успел еще фичей докрутить.

Да куда мне править — разобраться бы Но спасибо, настроение чудесное, очень интересно.

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

_FR>Что-то в примерах ничего похожего не нашёл, а на

_FR>

_FR>class Foo
_FR>{
_FR>  public MyValue : int { get; set; }
_FR>}

_FR>def f = Foo() { MyValue = 1, };
_FR>

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

В языке есть именованные параметры, так что если будет конструктор (например, сгенерированный макрой Record, как показал WolfHound), то можно писать вот так:

def f = Foo(myValue = 1);

Это работает даже если у конструктора есть много параметров.

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

VD>Это работает даже если у конструктора есть много параметров.

Но указать их придется ровно все (с точностью до перегрузки).

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

_FR>Но преобразование одного из другого делается простым переименованием?
Да.

_FR>Сойдёт. просто у меня дома ноут слабенький, студии там нету (хотя думаю Express поставить). Но Nemerle Studio вроде как летает.
Так Nemerle Studio и есть этот самый экспрес.
В любом случае я не вижу никаких причин почему полноценная студия должна есть ресурсов больше чем экспресс.

_FR>Да куда мне править — разобраться бы Но спасибо, настроение чудесное, очень интересно.
Так одно другому не мешает.

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

VD>Синтаксис инициализаторов не реализован. Как-то по жизни не было необходимости, а делать что-то просто для галочки не хотелось.

Я нашёл что-то с with в модуле NRest (http://svn.assembla.com/svn/nrest/trunk/src/NRest/WithMacro.n), но что с этим делать не понял

VD>В языке есть именованные параметры, так что если будет конструктор (например, сгенерированный макрой Record, как показал WolfHound), то можно писать вот так:

Ага, в данном случае подходит — конструкторы метаданных свойств зависимости написаны правильные, так что всё путём

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

_FR>Спсмибо, уже нашёл

Страничка, кстати, сильно устарела. Я ее немного обновил.

_FR>Собственно, чего хотелось бы (просто скажите, что невозможно сделать, тогда не буде ерундой заниматься) на счёт свойств зависимости. Просто, кто знает, скажите, возможно или нет следующее:

_FR>1. Не указывать тело у геттеров и сеттеров:
_FR>

_FR>[DependencyProperty]
_FR>public SomeString : string { get; set; }
_FR>

_FR>Сейчас генерится поле и компилятор даёт справедливый ворнинг. Хотелось бы, что бы макрос можно было писать так и что бы поле не создавалось.

Сейчас сделано так, что преобразование автосвойств делается на этапе парсинга. Надо будет подумать над тем, чтобы это изменить, чтобы позволить использовать и такой синтаксис.

Сейчас можно добавить к описанию модификатор abstract и убрать его в макросе.

_FR>2. Из этого:
_FR>

_FR>[DependencyProperty]
_FR>public static SomeString : string { get; set; }
_FR>

_FR>Убрать из определения класса свойство, заменив его на два метода.

Хм. Сама идея удалять введенный пользователем код мне не нравится. Насколько помню удалять имеющиеся члены нельзя. Только преобразовывать.

_FR>3. разрешить вообще не указывать акессоры, предоставив реализацию по-умолчанию, то есть что бы вылидно было следующее (аттрибут упустил):
_FR>

_FR>public SomeString : string;  // => public get; public set;

_FR>public SomeString : string { private set; }; // => public get; private set;
_FR>public SomeString : string { get; }; // => public get; private set;
_FR>

Это можно.

_FR>4. Это принципиаольно, что NemerleStudion работает с nsln и не открывает простые sln?

Деталей не знаю, но это действительно так.

_FR>5. Автокомплит будет улучшаться? Сейчас приходится явно жать Ctrl+Space, а хотелось бы что бы само появлялось по нажатии точки, как в шарпе.

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

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

_FR>5. Автокомплит будет улучшаться? Сейчас приходится явно жать Ctrl+Space, а хотелось бы что бы само появлялось по нажатии точки, как в шарпе.

Выложил инсталлятор для ревизии 8745. Там список автодополенния открывается по по точке.
(будет доступен для скачивания минут через 10).

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

WH>В любом случае я не вижу никаких причин почему полноценная студия должна есть ресурсов больше чем экспресс.

Она грузит ряд левых пакетов помечанных как "автозагружаемые". Если не ошибаюсь даже С++-ный пакет так помечен.

_FR>>Да куда мне править — разобраться бы Но спасибо, настроение чудесное, очень интересно.
WH>Так одно другому не мешает.

+1

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

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

VD>>Синтаксис инициализаторов не реализован. Как-то по жизни не было необходимости, а делать что-то просто для галочки не хотелось.

_FR>Я нашёл что-то с with в модуле NRest (http://svn.assembla.com/svn/nrest/trunk/src/NRest/WithMacro.n), но что с этим делать не понял

VD>>В языке есть именованные параметры, так что если будет конструктор (например, сгенерированный макрой Record, как показал WolfHound), то можно писать вот так:

_FR>Ага, в данном случае подходит — конструкторы метаданных свойств зависимости написаны правильные, так что всё путём

Этот макрос-оператор как раз реализует идею инициализатора Его можно как он есть засунуть в отдельную сборку, а потом ее добавить Macro Reference к основному проекту, открыть пространство имен — и можно пользоваться. Вот — нарисовал проект простой, демонстрирующий идею.

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

H>Но указать их придется ровно все (с точностью до перегрузки).

Нет.

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

H>Этот макрос-оператор как раз реализует идею инициализатора Его можно как он есть засунуть в отдельную сборку, а потом ее добавить Macro Reference к основному проекту, открыть пространство имен — и можно пользоваться. Вот — нарисовал проект простой, демонстрирующий идею.

Добавил в сниппеты.
Если кто-то захочет, то лежит в NewObjectMacro.dll.