Здравствуйте, _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#.
Здравствуйте, _NN_, Вы писали:
_NN>Однако возможно этот шаг поможет найти еще сторонников из мира C#.
В Немреле столько фич, что все сторонники шарпа уже по 10 раз должны были перейти на немерл. Так что еще одна вряд ли на что-то повлияет. Плюс, чем больше фич, тем сложнее учить язык.
_NN>Я вот не понимаю зачем нужно придумывать имя переменной в методах расширения и почему нельзя было сделать как указано выше
Фарш невозможно провернуть назад. (с)
Можно подумать о более простом (и возможно, менее элегантном) решении. Например, использовать для описания свойства-расширения методы с атрибутами.
Здравствуйте, VladD2, Вы писали:
VD>Тогда их можно будет вызвать как метод. А возможность обращаться к ним как к свойствам будет всего лишь небольшим синтаксическим сахаром.
По сути компилятор именно это и будет генерировать. Можно для начала и так.
А можно и макрос приделать для генерации
И даже квазицитаты новые не требуются.
public staticextension X : int (this m : MyClass) { get { m.Y + 1 } set { m.Y = value - 1 } }
А вариант 2 приберечь для N2 или N1.x.
Только бы не забыть о нём.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, VladD2, Вы писали:
VD>>И то, и то, как-то некузяво. Второй вариант совсем не похож на методы-расширения. Какой-то не явный параметр. Первый просто странный.
_NN>Кстати подумалось, а почему расширения не используют синтаксис _NN>
Здравствуйте, Jack128, Вы писали:
J>using NS1; J>using NS2;
J>в обоих неймспейсах есть одинаковый extension метод ExtensionMethod
J>как вызвать ExtensionMethod из NS1??
Очевидно тут тоже нужен будет другой синтаксис
myObject.NS1.MyExtensions.ExtensionMethod();
А если NS1 есть у myObject, то myObject.global::NS1.MyExtensions.ExtensionMethod();
Или там придумать другой синтаксис типа: myObject.<NS1.MyExtensions.ExtensionMethod>();
P.S.
Я понимаю, нужно все продумать прежде чем бросаться в крайности.
На это и форум
Здравствуйте, VladD2, Вы писали:
VD>Да и как вообще можно сделать события расширениями? Кто их вызвать то будет?
Кто-нибудь другой, естественно.
// без событий-расширений
SomeSingletonList.Add(x);
SomeSingletonList.Event += myHandler;
// с ними
x.Event += myHandler;
Мне кажется, библиотеки вроде Reactive Extensions очень бы выиграли от событий-расширений.
Можно конечно включить фантазию и добавить еще события с индексаторами (и соответствующие расширения), но это уж вряд ли найдет поддержку у коммьюнити
Здравствуйте, VladD2, Вы писали:
VD>Можно подумать о более простом (и возможно, менее элегантном) решении. Например, использовать для описания свойства-расширения методы с атрибутами.
VD>
Здравствуйте, catbert, Вы писали:
C>А в чем, собственно, проблема? Почему нельзя использовать стандартный синтаксис индексаторов + ключевое слово this?
А в чем смысл использования синтаксиса индексаторов? Мы хотим всех запутать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А в чем смысл использования синтаксиса индексаторов? Мы хотим всех запутать?
Мне кажется абсолютно логичным и ничуть не запутанным использование
public static PropertyName[this x : Type1] : Type2
{
...
}
для обозначения свойств-расширений.
Для того чтобы превратить метод класса в метод-расширение, мне нужно объявить его публичным, статическим, добавить аргумент с обозначением this, и заменить все ссылки на this внутри метода на этот аргумент.
Для того чтобы превратить свойство класса в свойство-расширение, мне нужно объявить его публичным, статическим, добавить индекс с обозначением this, и заменить все ссылки на this внутри свойства на этот аргумент.
По-моему, все симметрично и понятно. И новый синтаксис не вводится. Держу пари, что если в C# когда-нибудь введут свойства-расширения, у них будет именно такой синтаксис.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
VD>>А в чем смысл использования синтаксиса индексаторов? Мы хотим всех запутать?
C>Мне кажется абсолютно логичным и ничуть не запутанным использование
C>
C> public static PropertyName[this x : Type1] : Type2
C> {
C> ...
C> }
C>
C>для обозначения свойств-расширений.
А свойства индексаторы как будут выглядеть?
public static PropertyName[this x : Type1] [index : int] : Type2 { .. }
J>using NS1; J>using NS2;
J>в обоих неймспейсах есть одинаковый extension метод ExtensionMethod
J>как вызвать ExtensionMethod из NS1??
Точно так же как сейчас. Статик методом с первым параметром, весь этот синтаксис все равно будет транслироваться в него. Свойства тоже должны быть странслированы в get_PropertyName/set_PropertyName, чтобы их было легко использовать из внешних библиотек.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Jack128, Вы писали:
J>>using NS1; J>>using NS2;
J>>в обоих неймспейсах есть одинаковый extension метод ExtensionMethod
J>>как вызвать ExtensionMethod из NS1??
Z>Точно так же как сейчас. Статик методом с первым параметром, весь этот синтаксис все равно будет транслироваться в него. Свойства тоже должны быть странслированы в get_PropertyName/set_PropertyName, чтобы их было легко использовать из внешних библиотек.
а сейчас в N разрешено вызывать непосредственно геттеры/сеттеры свойств? Не extension, а обычных свойств?
Здравствуйте, VladD2, Вы писали: VD>На практике у меня пару раз возникало желание сделать свойство-расширение. А вот события или индексеры ни разу.
VD>Да и как вообще можно сделать события расширениями? Кто их вызвать то будет?
в WPF исползуются AttachedEvent's как и AttachedProprty но нету поддержки сто тсороны С#, только с XAML
а с С# выглядит вот так:
// это AttachedPropery чтобы присвоить соответственно надо вызвать SetDragpublic static readonly DependencyProperty TypeProperty = DependencyProperty.RegisterAttached("Type",
typeof(Type),
typeof(DependencyObject),
new PropertyMetadata((d, e) => SetTypes(d, new Type[] { (Type)e.NewValue })));
public static void SetType(DependencyObject d, Type v)
{
d.SetValue(TypeProperty, v);
}
public static Type GetType(DependencyObject d)
{
return (Type)d.GetValue(TypeProperty);
}
//А это соответсвенно аналогичный ивентpublic static readonly RoutedEvent DropEvent = EventManager.RegisterRoutedEvent("Drop", RoutingStrategy.Bubble,
typeof(Action<UIElement, DropEventArgs>),
typeof(DependencyObject));
public static void AddDropHandler(UIElement source, Action<UIElement, DropEventArgs> handler)
{
source.AddHandler(DropEvent, handler);
}
public static void RemoveDropHandler(UIElement source, Action<UIElement, DropEventArgs> handler)
{
source.RemoveHandler(DropEvent, handler);
}
Вызов из XAML весьма удобочитаем, а вот из кода работать не так удобно, так что таки надо свойства/ивенты расширения.
Здравствуйте, BogdanMart, Вы писали:
BM>Вызов из XAML весьма удобочитаем, а вот из кода работать не так удобно, так что таки надо свойства/ивенты расширения.
Тому, кому захочется — элементарно засахарит макрооператором эти акцессоры для свойств и событий:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, BogdanMart, Вы писали:
BM>>Вызов из XAML весьма удобочитаем, а вот из кода работать не так удобно, так что таки надо свойства/ивенты расширения.
Во:
obj.Prop from AttachedPropertyClass = 10;
obj.Event from AttachedPropertyClass += value;
Здравствуйте, VladD2, Вы писали:
VD>А как оформить обычные индексаторы с несколькими аргументами?
Да так же, только без this. Все точно так же, как с методами.
VD>Не ужели вам самим не ясно, что идея использовать синтаксис индексеров для описания чего-то отличного от индексеров — это плохая идея?
Индексеры — это те же свойства, только с параметрами. Я бы даже сказал, обычные свойства-члены — это индексеры, в которых один параметр (this) спрятан. В свойствах-расширениях он просто явный.
Давайте еще раз посмотрим на объявления методов и индексеров:
class C
{
// метод-член без параметровpublic Foo() : ReturnType { ... }
// метод-расширение без параметровstatic Foo(this self : C) : ReturnType { ... }
// метод-член с одним параметромpublic Foo(parm : Type1) : ReturnType { ... }
// метод-расширение с одним параметромstatic Foo(this self : C, parm : Type1) : ReturnType { ... }
// свойство-членpublic Foo : ReturnType { ... }
// свойство-расширениеpublic Foo[this self : C] : ReturnType { ... }
// свойство-член с одним параметром (индексер)public Foo[parm : Type1] : ReturnType { ... }
// свойство-ресширение с одним параметром (индексер)public Foo[this self : C, parm : Type1] : ReturnType { ... }
}
Разница (не считая скобок) между методами и свойствами/индексер одна — после свойства-члена Foo нету скобок.
Может мне только кажется, но синтаксиса логичнее (и менее "удивительного") не придумаешь.
Здравствуйте, catbert, Вы писали:
VD>>А как оформить обычные индексаторы с несколькими аргументами?
C>Да так же, только без this. Все точно так же, как с методами.
Я об обычных индексаторах-расширениях с несколькими аргументами.
VD>>Не ужели вам самим не ясно, что идея использовать синтаксис индексеров для описания чего-то отличного от индексеров — это плохая идея?
C>Индексеры — это те же свойства, только с параметрами.
Свойства с параметрами — это уже звучит глупо.
Индексеры — это индексеры. Закос на доступ по индексу к массивам.
C>Я бы даже сказал, обычные свойства-члены — это индексеры, в которых один параметр (this) спрятан. В свойствах-расширениях он просто явный.
Эдак можно договориться до чего угодно.
C> // свойство-расширение
C> public Foo[this self : C] : ReturnType { ... }
C> // свойство-член с одним параметром (индексер)
C> public Foo[parm : Type1] : ReturnType { ... }
C> // свойство-ресширение с одним параметром (индексер)
C> public Foo[this self : C, parm : Type1] : ReturnType { ... }
C>}
На мой взгляд — это совершено не очевидно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Jack128, Вы писали:
J>а сейчас в N разрешено вызывать непосредственно геттеры/сеттеры свойств? Не extension, а обычных свойств?
Да. Причем эта багофича еще и полезна, так как позволяет легко превратить свойство в функцию ссылку на функцию. В интеллисенсе, это правда закрыто. Но если не полениться и дописать get_ вручную, то будет работать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Тогда это будет и преемственно по синтаксису с текущей реализацией методов-расширений, и понятно, и просто в реализации.
Сам я этим не хочу заниматься, так как в ближайшее время, после выпуска релиза интеграции с VS 2010 хочу сесть за IKVM-бэкэнд. Эта фича нам сейчас нужна больше всего, на мой взгляд. Да и IT я уже ее пообещал.
Если кто-то хочет заняться реализацией свойств-расширений, то можете приступать. Я постараюсь помочь советами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _NN_, Вы писали:
VD>В общем, после обсуждения мое мнение такое. Если делать свойства-расширения, то синтаксис нужно выбирать наиболее простой и кондовый: VD>
А после реализации свойств, индексаторов и событий расширения, мы, при привязке оных к интерфейсам, фактически получим Сишные шаблоны с прилагающимся множественным наследованием. ^______^
Может, майкрософт потому и не торопится их реализовывать?
Здравствуйте, EqKeeper, Вы писали:
EK>А после реализации свойств, индексаторов и событий расширения, мы, при привязке оных к интерфейсам, фактически получим Сишные шаблоны с прилагающимся множественным наследованием. ^______^
Из чего это вытекает. Мне кажется у вас ложные предпосылки.
Шаблоны С++ — это средство обобщения кода во время компиляции и за одно система метапрограммирования. Наличие или отсутствие свойств тут мало что изменяет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.