Наконец-то можно создавать формы одним выражением:
Скрытый текст
def f = Form() with
{
Font = Drawing.Font("Segoe UI", 9);
Text = "hello";
Width += 100;
Height -= 100;
Controls with
[
Panel() with
{
Controls with
[
ListBox() with
{
IntegralHeight = false;
Dock = DockStyle.Fill;
Name = "second";
},
ListBox() with
{
Dock = DockStyle.Left;
Name = "first";
Items with [3, 4, 5];
Items ::= otherItems;
IntegralHeight = false;
SelectedIndexChanged +=
(s, _) =>
{
def first = (s :> ListBox);
def second = first.Parent.Controls["second"] :> ListBox;
second.DataSource = first.SelectedItem.ToString().ToArray();
}
}
];
Dock = DockStyle.Fill;
},
Button() with
{
Text = "push me";
Dock = DockStyle.Top;
Click => _ = k.Start();
},
TextBox() with
{
Text = "type in me";
Dock = DockStyle.Bottom;
}
];
}
Здравствуйте, Ka3a4oK, Вы писали:
C>>Наконец-то можно создавать формы одним выражением:
KK>В чем профит?
Во-первых, в WinForms часто используются императивные фичи языка: события, коллекции, изменяемые классы. Эта возможность — индикатор того, насколько макрос с ними справляется.
Во-вторых, создание форм с новым макросом удобнее, чем со старым, а тем более, чем без него. Просто потому что неудобно сначала декларировать вложенные контролы, а потом внешние. Ну, и еще менее удобно потом навешивать обработчики событий. А с этим макросом я формы клепаю быстрее, чем в дизайнере на C# (особенно на ноуте, где дизайнер тормозит безбожно)
Здравствуйте, catbert, Вы писали:
C>Народ хотел инициализаторы коллекций, так что я решил поделиться
Да-да, это я хотел! Спасибо огромное, catbert! Избалованные сахаром /диабетчики/ люди, переходящие с цэшарпа, с большим трудом приспосабливаются к многословному коду.
C>5. Поддержка метода AddRange C>
Этого, как я понимаю, нет даже в цэшарпе! КрутЪ!
C>Наконец-то можно создавать формы одним выражением: C> def f = Form() with C> { C> Font = Drawing.Font("Segoe UI", 9);
Несмотря на поддержку дизайнера, мне кажется, это будет востребовано. Уж для "обычных" (и иногда "ветвистых") объектов точно!
А что нуна делать, чтобы всё это заработало? Просто скопировать в "c:\Program Files\Nemerle\CodeSnippets\Snippets" или нужно перекомпилировать?
Здравствуйте, matumba, Вы писали:
M>А что нуна делать, чтобы всё это заработало? Просто скопировать в "c:\Program Files\Nemerle\CodeSnippets\Snippets" или нужно перекомпилировать?
Собрать проект с макросом а бинарник подключить макрореференсом к проекту.
C>2. Инициализация коллекций C>3. Вложенная инициализация без создания объектов C>4. // упрощенная форма, как в компиляторе Mono C# C>5. Поддержка метода AddRange
Это особенно здорово, просто праздник какой-то! Одной макрой застыдил си-решетку.
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, Ka3a4oK, Вы писали:
C>>>Наконец-то можно создавать формы одним выражением:
KK>>В чем профит?
C>Во-первых, в WinForms часто используются императивные фичи языка: события, коллекции, изменяемые классы. Эта возможность — индикатор того, насколько макрос с ними справляется.
C>Во-вторых, создание форм с новым макросом удобнее, чем со старым, а тем более, чем без него. Просто потому что неудобно сначала декларировать вложенные контролы, а потом внешние. Ну, и еще менее удобно потом навешивать обработчики событий. А с этим макросом я формы клепаю быстрее, чем в дизайнере на C# (особенно на ноуте, где дизайнер тормозит безбожно)
А может стоит этот макрос совместить с дизайнером WinForms?
Здравствуйте, _FRED_, Вы писали:
_FR>Разработчики шарпа решили, что "Да", найдя для этого достаточно оснований
_FR>Если у вас есть свой вижен, то, может, позволить так же (если ещё нет) использовать и extension Add-методы?
По видимому, используется нетипизированный подход, и, с чем свяжется имя Add, уже решится механизмом выбора перегрузок. Если по сигнатуре подойдет метод-расширение, то будет использован он. Я не вижу потенциальных проблем с этим, но обоснование проверки на IEnumerable приветстувуется
Здравствуйте, hardcase, Вы писали:
H>По видимому, используется нетипизированный подход, и, с чем свяжется имя Add, уже решится механизмом выбора перегрузок. Если по сигнатуре подойдет метод-расширение, то будет использован он. Я не вижу потенциальных проблем с этим, но обоснование проверки на IEnumerable приветстувуется
ну в шарпе таким образом пытаются гарантировать, что смысл операции new SomeClass(10) { 1 } — добавление элемента в коллекцию элементов, а не например сложение двух чисел. ПОнятно, что это просто попытка, но тем ни менее..
Здравствуйте, Jack128, Вы писали:
J>ну в шарпе таким образом пытаются гарантировать, что смысл операции new SomeClass(10) { 1 } — добавление элемента в коллекцию элементов, а не например сложение двух чисел. ПОнятно, что это просто попытка, но тем ни менее..
Здравствуйте, _nn_, Вы писали:
__>А может стоит этот макрос совместить с дизайнером WinForms?
Можно, но для этого надо добавить в него еще как минимум одну фичу (присваивать полученные значения переменным класса). Кроме того, нужно разобраться с CodeDom'ом и вызовами методов посреди инициализации.
Это конечно добавит читаемости в код дизайнера, но стабильности, боюсь, не добавит .
Ну, и еще, тогда этот макрос придется перенести в стандартную библиотеку.
Здравствуйте, VladD2, Вы писали:
VD>Комплит водр работает?
Не знаю, что такое "водр" , но с правой стороны присваиваний автокомплит через Ctrl+Space работает. С левой стороны — нет, и я не представляю, как его добавить.
Здравствуйте, catbert, Вы писали:
C>Не знаю, что такое "водр" , но с правой стороны присваиваний автокомплит через Ctrl+Space работает. С левой стороны — нет, и я не представляю, как его добавить.
Опять же погляди макру ?. я там эте проблему тоже решил.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Допилил макрос и компилятор. Теперь для макроса with доступен интлеллисенс (хинты, переход к определению, подсветка использования, автодополнение при вводе).
Допиливание в компиляторе свелось к тому, чтобы код типа:
Можно перенести это дело в стандартную библиотеку макросов.
Но есть одна недоработка. Эту штуку нужно поддерживать в макросе поддрежки linq. Там инициализация объекта с with должна переписываться во что-то вроде:
Предлагаю внести данный макрос в состав стандартной библиотеки. А то он слишком мал чтобы ради него цеплять отдельную сборку, но штука может оказаться полезной для многих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
) хотел инициализаторы коллекций, так что я решил поделиться, и обновил реализацию with-макроса в сниппетах. Поддерживаются новые фичи.
Макрос переехал в стандартную библиотеку в пространство имен Nemerle.Extensions.
К сожалению, использовать оригинальное имя "with" в качестве имени оператора не вышло: виртуальный оператор с таким именем, используемый для поддержки PM-а, имеет неподходящие приоритеты. Использована синтетическая штуковина: <-. Пример тут. Как и макра анонимного типа, инициализатор пока не отражен в официальной документации.
) хотел инициализаторы коллекций, так что я решил поделиться, и обновил реализацию with-макроса в сниппетах. Поддерживаются новые фичи.
H>Макрос переехал в стандартную библиотеку в пространство имен Nemerle.Extensions. H>К сожалению, использовать оригинальное имя "with" в качестве имени оператора не вышло: виртуальный оператор с таким именем, используемый для поддержки PM-а, имеет неподходящие приоритеты. Использована синтетическая штуковина: <-.
Жаль. Впрочем, <- сойдет
H>Как и макра анонимного типа, инициализатор пока не отражен в официальной документации.
Как лучше всего это исправить? Мне кажется, стоит добавить доки в CSharpDiff и в раздел Macros.
Здравствуйте, catbert, Вы писали:
C>Как лучше всего это исправить? Мне кажется, стоит добавить доки в CSharpDiff и в раздел Macros.
Можно в принципе, но мне кажется, что эта страница слишком перегружена. Наши реализации анонимных типов и инициализаторов существенно функциональнее и вполне тянут на выделенные страницы. А в CSharpDiff можно небольшие примеры поместить с отсылкой на полные статьи.
Здравствуйте, hardcase, Вы писали:
H>К сожалению, использовать оригинальное имя "with" в качестве имени оператора не вышло: виртуальный оператор с таким именем, используемый для поддержки PM-а, имеет неподходящие приоритеты. Использована синтетическая штуковина: <-.
Вот тебе, бабушка, и Юрьев… то есть оператор стрелка
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, hardcase, Вы писали:
_FR>>Вот тебе, бабушка, и Юрьев… то есть оператор стрелка
H>Подругому не получилось.
Ага. Стрелка в обратную сторону выглядит страшно не удобно. Но чего-то на замену тоже не придумывается. Жаль, что нельзя сделать как в шарпе
H>Вообще у нас уже есть оператор стрелка (в другую сторону), он используется для декларации функционального типа:
H>int * string -> bool
Такие стрелки как-то мозг не ломают (текст-то набирается справа на лево).
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Ага. Стрелка в обратную сторону выглядит страшно не удобно. Но чего-то на замену тоже не придумывается. Жаль, что нельзя сделать как в шарпе
По-моему, как в шарпе сделать можно. Для этого придется склеить макросы анонимных типов и инициализатора.
Здравствуйте, _FRED_, Вы писали:
_FR>Ага. Стрелка в обратную сторону выглядит страшно не удобно. Но чего-то на замену тоже не придумывается. Жаль, что нельзя сделать как в шарпе
Чтобы сделать как в шарпе надо курочить компилятор. Макросы Н1 на это не способны. Думаю, что в Н2 макрам это будет под силу.
H>>Вообще у нас уже есть оператор стрелка (в другую сторону), он используется для декларации функционального типа: _FR>
H>>int * string -> bool
_FR>
_FR>Такие стрелки как-то мозг не ломают (текст-то набирается справа на лево).
В F# <- используется вместо оператора присвоения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_FR>>Ага. Стрелка в обратную сторону выглядит страшно не удобно. Но чего-то на замену тоже не придумывается. Жаль, что нельзя сделать как в шарпе VD>Чтобы сделать как в шарпе надо курочить компилятор. Макросы Н1 на это не способны. Думаю, что в Н2 макрам это будет под силу.
H>>>Вообще у нас уже есть оператор стрелка (в другую сторону), он используется для декларации функционального типа:
H>>>int * string -> bool
_FR>>Такие стрелки как-то мозг не ломают (текст-то набирается справа на лево). VD>В F# <- используется вместо оператора присвоения.
Ага, что очень мешает даже при чтении книжек Но дело конечно же в привычке
Help will always be given at Hogwarts to those who ask for it.
Re[7]: [Snippets] Обновленный макрос with
От:
Аноним
Дата:
17.03.11 06:42
Оценка:
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, VladD2, Вы писали:
_FR>>>Ага. Стрелка в обратную сторону выглядит страшно не удобно. Но чего-то на замену тоже не придумывается. Жаль, что нельзя сделать как в шарпе VD>>Чтобы сделать как в шарпе надо курочить компилятор. Макросы Н1 на это не способны. Думаю, что в Н2 макрам это будет под силу.
_FR>
H>>>>Вообще у нас уже есть оператор стрелка (в другую сторону), он используется для декларации функционального типа: _FR>
H>>>>int * string -> bool
_FR>
_FR>>>Такие стрелки как-то мозг не ломают (текст-то набирается справа на лево). VD>>В F# <- используется вместо оператора присвоения.
_FR>Ага, что очень мешает даже при чтении книжек Но дело конечно же в привычке
) хотел инициализаторы коллекций, так что я решил поделиться, и обновил реализацию with-макроса в сниппетах. Поддерживаются новые фичи.
H>Макрос переехал в стандартную библиотеку в пространство имен Nemerle.Extensions. H>К сожалению, использовать оригинальное имя "with" в качестве имени оператора не вышло: виртуальный оператор с таким именем, используемый для поддержки PM-а, имеет неподходящие приоритеты. Использована синтетическая штуковина: <-. Пример тут. Как и макра анонимного типа, инициализатор пока не отражен в официальной документации.
new в PM вроде не используется.
Может все же можно его использовать ?
) хотел инициализаторы коллекций, так что я решил поделиться, и обновил реализацию with-макроса в сниппетах. Поддерживаются новые фичи.
H>Макрос переехал в стандартную библиотеку в пространство имен Nemerle.Extensions. H>К сожалению, использовать оригинальное имя "with" в качестве имени оператора не вышло: виртуальный оператор с таким именем, используемый для поддержки PM-а, имеет неподходящие приоритеты. Использована синтетическая штуковина: <-. Пример тут. Как и макра анонимного типа, инициализатор пока не отражен в официальной документации.
Крутая макра!!! НАконецто можно декларативно создавать формочки из немерловского кода.
Если доработать то и поддержка XAMLa будет не нужна.
Чего не хватало в оригинальном макросе -- возмодности присваивать промежуточные результаты глобальной области видимости (те. формочка создаеться макросом и все ее содержымое, но какой-то TextBox также помещается в переменную)
Обратить внимание на места lbl <- Label() и txtBox <- TextBox() то есть помещаем во внешнюю переменную(или поле класса) текущие контролы.
Приимущества:
Весь код формы находиться в одном месте, а не размазан по местам где создаются нужные переменные(и контрольчики)
нужные контрольчики лежат в переменных
Ну мешать эту макру с "<-" не обязательно, просто этот символ для этого действия ажеться логичным(и другого не придумал) а оператор "=" как ихвестно имеет тип возврата void по этому надо как то выкручиваться
Желаю услышать ваши мнения. Если катит то доведу до ума и закомичу ибо ИМХО полезная доработка для этого макроса.
Здравствуйте, BogdanMart, Вы писали:
ВМ>Чего не хватало в оригинальном макросе -- возмодности присваивать промежуточные результаты глобальной области видимости
Так, правда, приходится создавать переменные сверху. Чтобы автоматически добавлять переменные в область видимости (но это уже другой вопрос!), можно добавить оператор as, как в паттерн-матчинге:
def w = Window() <-
{
Content = StackPanel() as pnl <-
{
Children <-
[
TextBox() as this.txtBox <- { blah blah } // если написано this, то генерируется член класса, а не локальная переменная
]
}
}
Преимущество в том, что повторно используется стандартный синтаксис ввода в область видимости. Недостаток в том, что Немерле при этом на шаг приближается к С++, где все выражения вроде int *&, (int*)&, const int *, const * int, * const int позволены и имеют различную семантику. Но это так, философия
Здравствуйте, catbert, Вы писали:
C>Так, правда, приходится создавать переменные сверху. Чтобы автоматически добавлять переменные в область видимости (но это уже другой вопрос!), можно добавить оператор as, как в паттерн-матчинге:
C>
C>def w = Window() <-
C>{
C> Content = StackPanel() as pnl <-
C> {
C> Children <-
C> [
C> TextBox() as this.txtBox <- { blah blah } // если написано this, то генерируется член класса, а не локальная переменная
C> ]
C> }
C>}
C>
Идея хорошая с именами — они позволят записать инициализацию циклических структур:
def x = Node() as n <-
{
Parent = n
};
Фактически это имя можно использовать вместо временного имени, генерируемого компилятором.
C>def w = Window() <-
C>{
C> Content = StackPanel() as pnl <-
C> {
C> Children <-
C> [
C> TextBox() as this.txtBox <- { blah blah } // если написано this, то генерируется член класса, а не локальная переменная
C> ]
C> }
C>}
C>
Выглядит уже симпатично. Не придумал как cделать..
Вот только с введением переменных во внешнюю область видимости могут быть сложности.. Компилятор вроде бы автоматически ставит блок вокруг тела макроса.. значит объявленные переменные будут внутри блока.
Здравствуйте, BogdanMart, Вы писали:
BM>Выглядит уже симпатично. Не придумал как cделать.. BM>Вот только с введением переменных во внешнюю область видимости могут быть сложности.. Компилятор вроде бы автоматически ставит блок вокруг тела макроса.. значит объявленные переменные будут внутри блока.
ставит если макрос из нескольких выражений, попробуй так:
C>mutable pnl : StackPanel;
C>mutable txtBox : TextBox;
C>def w = Window() <-
C>{
C> Content = StackPanel() as pnl <-
C> {
C> Children <-
C> [
C> TextBox() as this.txtBox <- { blah blah } // если написано this, то генерируется член класса, а не локальная переменная
C> ]
C> }
C>}
C>
Из макроса их объявить более глобально -- это куча гемора связанная с доставанием MethodBuilder'a из Typer'a а это уже шаманство.
Проще будет объявить нужную переменную
Не катит, потому что создания переносятся вверх... а если использовать первый способ то намного удобнее. И можно изменять тип контролов по требовании с меньшими затратами (все в одном месте лежит).
Хотя если вы знаете как по хорошему объявить переменную во внешней области.. то попробуйте..
ПС, как мне кажется даже с объявлением полей класса могут возникнуть проблемы, так как другие методы могут быть уже обработаны к этому моменту и не находить соответствующих полей(+ непонятно какую область видимости им давать, или может их свойствами, или вообще DependencyProperty) по этому лучше оставить объявление мест хранения объектиков на откуп пользователю.
H>mutable obj;
H>def x = X() <-
H>{
H> Y = Y() as out obj <-
H> {
H> A = ... // используем инициализированный obj здесь
H> B = ...
H> }
H>}
H>// а также уже после блока
H>
Конкретно именно так работать не будет ввиду специфики разбора out-выражение, но можно поискать решения типа:
mutable obj;
def x = X() <-
{
Y = out Y() as obj <-
{
A = ... // используем инициализированный obj здесь
B = ...
}
}
// а также уже после блока
Здравствуйте, BogdanMart, Вы писали:
BM>Тоесть полюбому не даст(напрямую, кончено можно из Тайпера получить MethodBuilder и потом колдовать, но брррр).
Макросы гигиеничны, переменную надо задавать так: $("var" : usesite).
BM>А еслибы и заработало с одним выражением, так нам надо и проретурнить и присвоить выражению.
Здравствуйте, hardcase, Вы писали:
H>Случай 1: использование имени внутри инициализатора
H>
H>def x = X() as current <-
H>{
H> // используем current для создания циклических структур данных
H>}
H>
public macro @as(obj, ing, initializer) // пробовал public macro @<-(obj, ing, initializer) как было в оригинале, не помогло..syntax( obj, "as", ing, "<-", initializer)
{
WithMacroImpl.Run(obj, initializer);
}
def _w = Window() as temp <- {}
выдает: Error: found pattern expression () inside a raw expression
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, BogdanMart, Вы писали:
BM>>Здравствуйте, hardcase, Вы писали:
BM>>Офигеть.Почти так же писал матч... и ни черта не работало... мистика какая-то. Спасибо!
H>На самом деле такая полиморфность поведения X() as x не удачна, использование выражения out возможно лишь в правой части оператора <- H>
H>X() as x <- out ....
H>
Но по-моему это некрасиво...
H>Как вариант, избавиться от неоднозначности (для программиста) можно таким способом: H>
H>X() as x! <- .... // кстати !x тоже будет работать :)
H>
Спасибо, выглядит неплохо. Единственно что пользователь может для своего класса перегрузить "!" но такое врятли произойдет (что он будет пытаться проинициализоровать объект порожденный оператором ! )
Здравствуйте, BogdanMart, Вы писали:
BM>Спасибо, выглядит неплохо. Единственно что пользователь может для своего класса перегрузить "!" но такое врятли произойдет (что он будет пытаться проинициализоровать объект порожденный оператором ! )
афайк, разбор макроса произойдет до применения оператора.
Здравствуйте, VladD2, Вы писали:
VD>Блин! На фиг этот птичий язык уперся? Вы в погоне за прекрасным делаете какую-то жопу. И это явно не жопа молодой красивой девушки.
Предложи как по лучше его завернуть в плане синтаксиса.
(а фитча сама по себе нужная, в стандартной либе валяется, но возможности присваивать значения явно не хватает)
Здравствуйте, BogdanMart, Вы писали:
BM>Предложи как по лучше его завернуть в плане синтаксиса.
Я вообще этим делом не пользуюсь. Да и хватает того что нужно сделать без этого.
BM>(а фитча сама по себе нужная, в стандартной либе валяется, но возможности присваивать значения явно не хватает)
Я не уверен, что она нужна. Надо что-то менять в объекте, получи это и меняй.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BogdanMart, Вы писали:
BM>>Предложи как по лучше его завернуть в плане синтаксиса.
VD>Я вообще этим делом не пользуюсь. Да и хватает того что нужно сделать без этого.
BM>>(а фитча сама по себе нужная, в стандартной либе валяется, но возможности присваивать значения явно не хватает)
VD>Я не уверен, что она нужна. Надо что-то менять в объекте, получи это и меняй.
Вся фишка немерлы в том тчобы писать меньше более структурированного кода а получать больше пользы.
Попробуй создать пользовательский интерфес средней сложности из кода (и без этого макроса) и увидишь какой "красивый" код получиться в результате.
Но если не нравиться то перенеси обратно в снипеты из основной либы. Но по моему это как раз таки огромным козырем станет для немерлы. Шарп ито в каком то виде это делать умеет.
по поводу полезности:
public Tags : IDTags
{
get
{
IDTags() <-
{
Title = Title;
Artist = ArtistName;
Album = AlbumName;
Year = if(Year == 0) this.Album.Year else this.Year;
No = TrackNo;
Genre = Genre;
Length = length;
Size = Size;
Rate = Rate;
}
}
}
против
public Tags : IDTags
{
get
{
def tags = IDTags();
tags.Title = Title;
tags.Artist = ArtistName;
tags.Album = AlbumName;
tags.Year = if(Year == 0) this.Album.Year else this.Year;
tags.No = TrackNo;
tags.Genre = Genre;
tags.Length = length;
tags.Size = Size;
tags.Rate = Rate;
tags
}
}
По моему првый способ НАМНОГО выразительнее. Хотя конкретно в этом случае отсутствие этого макроса сильно большого дискомфорта не создаст, а вот при создании древовидных структур жесть начнется.
Здравствуйте, VladD2, Вы писали:
VD>Я не уверен, что она нужна. Надо что-то менять в объекте, получи это и меняй.
Оу, речи шла об возврате значения... не сразу это понял. ну это опционально, но местами удобно. Желательно чтобы механизм был один на весь язык. Ато каждый себе реализует эту штуку по своему а код в результате не читаемый.
Здравствуйте, BogdanMart, Вы писали:
VD>>Я не уверен, что она нужна. Надо что-то менять в объекте, получи это и меняй.
BM>Оу, речи шла об возврате значения... не сразу это понял.
О том и речь. Если из-за финтифлюшки получится наврот который мало кто понять сможет, то на фиг она нужна?
Все равно ее использовать не будут, так как будут бояться запутаться. А если кто-то воспользуется, то потом никто понять не может.
В общем, с наворотами важно вовремя остановиться. Ведь совершенству предела нет, а в погони за ним легко не заметить и перейти грань разумного.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BogdanMart, Вы писали:
VD>>>Я не уверен, что она нужна. Надо что-то менять в объекте, получи это и меняй.
BM>>Оу, речи шла об возврате значения... не сразу это понял.
VD>О том и речь. Если из-за финтифлюшки получится наврот который мало кто понять сможет, то на фиг она нужна? VD>Все равно ее использовать не будут, так как будут бояться запутаться. А если кто-то воспользуется, то потом никто понять не может.
VD>В общем, с наворотами важно вовремя остановиться. Ведь совершенству предела нет, а в погони за ним легко не заметить и перейти грань разумного.
Да... это точно. Ну оно не понятно получилось. Но скажем я обявлю у себя макрос
macro AssignAndReturn(exp1, exp2)
{
<[
def tmp = $exp2;
$exp1 = tmp;
tmp;
]>
}
и буду его использовать как
def label;
Window() <-
{
Contetn = AssignAndReturn (label, Button()) <- {Content = "Click me!"}
}
Ну если использовать для дома для семьи то покатит, а если вдруг выложить где то как пример то уже и страшно и непонятно и надо разъяснять что твориться. (собрался клепать интерфейс на немерле в декларативном стиле)
P.S. > Почему в немерле оператор = имеет тип возврата void, если бы не это то и проблемы такой бы не было... в принципе
Здравствуйте, BogdanMart, Вы писали:
BM>P.S. > Почему в немерле оператор = имеет тип возврата void, если бы не это то и проблемы такой бы не было... в принципе
Здравствуйте, VladD2, Вы писали:
VD>О том и речь. Если из-за финтифлюшки получится наврот который мало кто понять сможет, то на фиг она нужна? VD>Все равно ее использовать не будут, так как будут бояться запутаться. А если кто-то воспользуется, то потом никто понять не может.
VD>В общем, с наворотами важно вовремя остановиться. Ведь совершенству предела нет, а в погони за ним легко не заметить и перейти грань разумного.
Собственно до грани разумного еще далеко, а финтифлюшка вполне полезная вырисовалась: именование под-объектов в выражении инициализатора (мне эта штука иногда нужна). Для этого предлагалось использовать оператор "as" в двух сценариях:
1) имя доступное лишь внутри выражения инициализации — для создания обратных ссылок: X() as x <- { используем где-то тут x }
2) имя переменной, в которое будет помещена ссылка на под-объект: X() as x! <- { ... } // где-то выше по коду объявлена изменяемая переменная x либо поле или свойство.
Здравствуйте, BogdanMart, Вы писали:
BM>P.S. > Почему в немерле оператор = имеет тип возврата void, если бы не это то и проблемы такой бы не было... в принципе
Потому же почему в нем имеют такой тип операторы ++ и -- — боролись со случайными ошибками. Ведь в императивных конструкциях их допустить очень легко. Не знаю уж добро при этом получилось или зло. Мне как старому сишнику по началу было непривычно и неудобно. Но на самом деле оно особо не напрягает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Собственно до грани разумного еще далеко,
На мой взгляд "X() as x! <- ..." — это уже за гранью разумного.
H>а финтифлюшка вполне полезная вырисовалась: именование под-объектов в выражении инициализатора (мне эта штука иногда нужна). Для этого предлагалось использовать оператор "as" в двух сценариях: H>1) имя доступное лишь внутри выражения инициализации — для создания обратных ссылок: X() as x <- { используем где-то тут x } H>2) имя переменной, в которое будет помещена ссылка на под-объект: X() as x! <- { ... } // где-то выше по коду объявлена изменяемая переменная x либо поле или свойство.
Лучше уж тогда было бы разрешить возврат значения оператором "<-" в рамках вашего макроса.
Его бы и для "=" бы разрешить. Но будут неоднозначности. Ведь человек может иметь в иду что выражение присваивающее значение переменной еще и возвращает его из составного выражения (функции, например).
Но в рамках вашего макроса инициализации — это прокатывает. Будете писать:
"X() <- x <- ..."
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Собственно до грани разумного еще далеко, а финтифлюшка вполне полезная вырисовалась: именование под-объектов в выражении инициализатора (мне эта штука иногда нужна). Для этого предлагалось использовать оператор "as" в двух сценариях: H>1) имя доступное лишь внутри выражения инициализации — для создания обратных ссылок: X() as x <- { используем где-то тут x } H>2) имя переменной, в которое будет помещена ссылка на под-объект: X() as x! <- { ... } // где-то выше по коду объявлена изменяемая переменная x либо поле или свойство.
Кстати, оператор <- можно был бы использовать и как замену оператору = которая бы возвращала бы значение (как = в C#). Не знаю уж получится ли совместить инициализатор и присвоение. Но если получится — это было бы прелестно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, оператор <- можно был бы использовать и как замену оператору = которая бы возвращала бы значение (как = в C#). Не знаю уж получится ли совместить инициализатор и присвоение. Но если получится — это было бы прелестно.
H>Хмм, а по-моему неплохо. Аналог цепочечных сишненьких присваиваний.
Имплементировал в r9752. Получилось что поддерживает <- для присвоения и для инициализации. И даже выкрутился для такого случая def p = Point() <- X=5;
Но код слегка запутанный вышел, так как пришлось две вещи лепить в один макрос.
Здравствуйте, Don Reba, Вы писали:
DR>Можно вопрос? Вот это не компилируется: DR>swapChainDescription не является ни ref ни out аргументом. В чём может быть проблема?
Единственное, что могу предположить — какие-то странные взаимодействия между struct-ом как аргументом для кода и блоками выражений.
Попробуйте заменить SwapChainDescription() <- {} на
{def x = SwapChainDescription(); x}
Этот код должен генерироваться макросом. Если ошибка останется, то это уже глюк компилятора, и я наверное ничем не смогу помочь. Если ошибка исчезнет, то глюк таки в макросе.
Здравствуйте, catbert, Вы писали:
C>Этот код должен генерироваться макросом. Если ошибка останется, то это уже глюк компилятора, и я наверное ничем не смогу помочь. Если ошибка исчезнет, то глюк таки в макросе.