Здравствуйте, _NN_, Вы писали:
_NN>Насколько сложно сделать ?
_NN>По сути свойства это вызов метода, но с другим синтаксисом. _NN>Раз методы расширения есть, то и свойства было бы хорошо добавить.
_NN>В C# возможно будут в будущем,а Nemerle это ведь будущее уже сейчас. _NN>Why No Extension Properties?
Ну, мне кажется, в основном проблемы в совместимости с потенциальными будущими свойствами расширения в С-шарпе, и ввода в язык статических свойств с индексатором.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>Насколько сложно сделать ?
_NN>>По сути свойства это вызов метода, но с другим синтаксисом. _NN>>Раз методы расширения есть, то и свойства было бы хорошо добавить.
_NN>>В C# возможно будут в будущем,а Nemerle это ведь будущее уже сейчас. _NN>>Why No Extension Properties?
C>Ну, мне кажется, в основном проблемы в совместимости с потенциальными будущими свойствами расширения в С-шарпе, и ввода в язык статических свойств с индексатором.
Будущими ? А когда это будет ?
В C# 5 вроде не планируется.
А он еще и не вышел.
А если в C# 6 добавят, то там и исправить можно.
Можно без поддержки индексаторов если в этом вся проблема.
А что собственно с ними ? В чем там проблема ?
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, _NN_, Вы писали:
_NN>>Насколько сложно сделать ?
_NN>>По сути свойства это вызов метода, но с другим синтаксисом.
H>Один вопрос. Нафига это вообще нужно?
Здравствуйте, hardcase, Вы писали:
H>Охренеть как удобно. Я согласен с Липпертом — игра не стоит свеч.
А зачем тогда обычные свойства? Вот джава-программеры обходятся getter-ами и setter-ами.
У свойств есть своя семантика. Свойство означает "я описываю состояние объекта, и меня можно быстро вызвать". Тот факт, что в С-шарпе свойства-расширения не осилили, не значит что они не нужны.
Здравствуйте, catbert, Вы писали:
C>У свойств есть своя семантика. Свойство означает "я описываю состояние объекта, и меня можно быстро вызвать". Тот факт, что в С-шарпе свойства-расширения не осилили, не значит что они не нужны.
Это очень редкий юзкейз — экстеншн метод с единственным аргументом. Я правильно понимаю, что после хотелки "экстеншн свойства" должны появиться экстеншн -события и экстеншн-индексаторы?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _NN_, Вы писали:
_NN>>Насколько сложно сделать ?
VD>Попробуй — узнаешь .
VD>Для начала обдумай каков будет синтаксис их объявления. Где будем this описывать?
Вариант 1.
publicstatic X : int{this m : MyClass} { get { m.Y + 1 } set { m.Y = value - 1 } }
Вместо {} любая другая пара скобок.
Вариант 2.
Тут this передается неявно.
publicstaticMyClass.X : int { get { this.Y + 1 } set { this.Y = value - 1 } }
В обоих вариантах код раскрывается в:
[ExtensionPropertyAttribute(Type = Getter)]
public static get_X(m : MyClass) : int { m.Y + 1 }
[ExtensionPropertyAttribute(Type = Setter)]
public static set_X(m : MyClass, value : int) : void { m.Y = value - 1 }
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, _NN_, Вы писали:
_NN>>Насколько сложно сделать ?
_NN>>По сути свойства это вызов метода, но с другим синтаксисом.
H>Один вопрос. Нафига это вообще нужно?
Например можно будет делать так:
def tm = 20.Minutes;
Сейчас это конечно можно решить макросом, но без него было бы проще:
Здравствуйте, _NN_, Вы писали:
_NN>Вариант 1. _NN>
_NN>publicstatic X : int{this m : MyClass} { get { m.Y + 1 } set { m.Y = value - 1 } }
_NN>
_NN>Вариант 2. _NN>Тут this передается неявно. _NN>
_NN>publicstaticMyClass.X : int { get { this.Y + 1 } set { this.Y = value - 1 } }
_NN>
И то, и то, как-то некузяво. Второй вариант совсем не похож на методы-расширения. Какой-то не явный параметр. Первый просто странный.
Как вариант:
public static X(this m : MyClass) : int { get { m.Y + 1 } set { m.Y = value - 1 } }
// илиpublic static X : int
{
this m : MyClass;
get { m.Y + 1 }
set { m.Y = value - 1 }
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Это очень редкий юзкейз — экстеншн метод с единственным аргументом. Я правильно понимаю, что после хотелки "экстеншн свойства" должны появиться экстеншн-события и экстеншн-индексаторы?
Не после, а прямо сейчас А юзкейс редкий, мне кажется, именно потому что нету экстеншен-свойств.
Здравствуйте, VladD2, Вы писали:
VD>Как вариант: VD>
VD>public static X(this m : MyClass) : int { get { m.Y + 1 } set { m.Y = value - 1 } }
VD>// или
VD>public static X : int
VD>{
VD> this m : MyClass;
VD> get { m.Y + 1 }
VD> set { m.Y = value - 1 }
VD>}
VD>
Да ладно уже, чем квадратные скобки плохи?
public static X[this m : MyClass] : int
{
get { m.Y + 1 }
set { m.Y = value - 1 }
}
Здравствуйте, VladD2, Вы писали:
VD>И то, и то, как-то некузяво. Второй вариант совсем не похож на методы-расширения. Какой-то не явный параметр. Первый просто странный.
Кстати подумалось, а почему расширения не используют синтаксис
Тогда бы не нужно было придумывать имя переменной, а использовался бы this.
И унификация
public staticMyClass.ExtensionMethod(p1 : Param1, p2 : Param2) : int { this.DoSomething(); }
public staticMyClass.ExtensionProperty : int { get { this.X } set { this.X = value } }
public staticMyClass.ExtensionEvent : MyEevnt { ... }
Здравствуйте, hardcase, Вы писали:
H>Это очень редкий юзкейз — экстеншн метод с единственным аргументом. Я правильно понимаю, что после хотелки "экстеншн свойства" должны появиться экстеншн -события и экстеншн-индексаторы?
Если делать свойства, то надо делать и события и индексаторы.
Здравствуйте, _NN_, Вы писали:
_NN>Кстати подумалось, а почему расширения не используют синтаксис _NN>
_NN>public staticMyClass.ExtensionMethod(p1 : Param1, p2 : Param2) : int { this.DoSomething(); }
_NN>public staticMyClass.ExtensionProperty : int { get { this.X } set { this.X = value } }
_NN>public staticMyClass.ExtensionEvent : MyEevnt { ... }
_NN>
В принципе не плохо. Но есть две проблемы:
1. Несовместимость с используемым синтаксисом для методов-расширений. Будут ломающие изменения.
2. Те кто приходят с шарпа могут путать такие описания с явной реализацией членов интерфейсов.
3. Довольно много переделок в парсере, так как синтаксис сильно отличается от исходного. Фактически нужно вводить новый вид квази-цитат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _NN_, Вы писали:
_NN>>Кстати подумалось, а почему расширения не используют синтаксис _NN>>
_NN>>public staticMyClass.ExtensionMethod(p1 : Param1, p2 : Param2) : int { this.DoSomething(); }
_NN>>public staticMyClass.ExtensionProperty : int { get { this.X } set { this.X = value } }
_NN>>public staticMyClass.ExtensionEvent : MyEevnt { ... }
_NN>>
VD>В принципе не плохо. Но есть две проблемы: VD>1. Несовместимость с используемым синтаксисом для методов-расширений. Будут ломающие изменения.
К сожалению это так
Можно оставить 2 синтаксиса и потом убрать старый.
VD>2. Те кто приходят с шарпа могут путать такие описания с явной реализацией членов интерфейсов.
В C# static нельзя написать для явной реализации.
Можно придумать другое ключевое слово: extension, например.
VD>3. Довольно много переделок в парсере, так как синтаксис сильно отличается от исходного. Фактически нужно вводить новый вид квази-цитат.
Это конечно серьезный аргумент.
Однако возможно этот шаг поможет найти еще сторонников из мира C#.