Здравствуйте, 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#). Не знаю уж получится ли совместить инициализатор и присвоение. Но если получится — это было бы прелестно.