Здравствуйте, Геннадий Васильев, Вы писали:
GZ>>Именно это я и имел ввиду. Синтаксис делегатов(не анонимов и не лямбд) мне кажется слишком сложным а эффективность не очень.
ГВ>Вот-вот, и как раз напрашивается риторический вопрос: почему делегаты не стали распространённым явлением в программах на C++.
Потому как понятие "функциональный объект" используется более широко в С++. Делал как-то свое GUI на С++, там делегаты работали на всю катушку, в остальных случаях всегда проще подать целевой функциональный объект (или ссылку на оный), чем непонятно для каких целей нужный делегат-посредник.
Что удобно (для тех кто не в С++), что функциональный объект — это или ф-ия сама по себе, или статический метод, или экземпляр класса/структуры/объединения, тип которого содержит operator()(...).
В дотнете мы можем некие действия/алгоритмы помещать только лишь в методы классов, причем эти методы не могут быть "функциональными объектами". Потому и нужен адаптер-переходник к некоему универсальному функциональному виду, то бишь делегат.
Re: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, VladD2, Вы писали:
VD>>Извини, но это глупость. Они в принципе разные! У них только синтаксис похож. Попробуй передать свойство по ссылке. GZ>И это плохо, что нельзя.
Блин, хотел по-быстрому накатать ссылку на св-во как объект (С# struct) из пары делегатов и переопределенного оператора implicit().
Однако, компилятор ругается на такой синтаксис:
PropRef<int> pr = new PropRef<int>(p1.get_P1, p1.set_P1);
Error 1 'ConsoleApplication1.Probe1.P1.get': cannot explicitly call operator or accessor
Блин, нельзя обратиться напрямую к акцессорам!
А через CreateDelegate — это надо PropertyInfo подавать, а получать его через рефлекшен, в общем статическая безопасность и типизация идет лесом... так же как и рефакторинг впоследствии...
А счастье было так близко...
Re[2]: Хорошо ли, что свойство нельзя передать по ссылке
Вопрос не в статической безопасности. Создать делегат указывающий на свойство, а будет ли это выглядеть "красиво" или нет — уже совсем другой вопрос.
Вопрос же скорее в следующем:
1. Что понимается вообще под _ссылкой_ на метод (и на свойство в частности)? Мне это не очень ясно. Более того сдается мне что делегат это совсем не ссылка.
2. Указатель на свойство создать вполне можно, хотя и используя менее удобный синтаксис чем в случае с обычным методом.
Re[3]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вопрос не в статической безопасности. Создать делегат указывающий на свойство, а будет ли это выглядеть "красиво" или нет — уже совсем другой вопрос. ВВ>Вопрос же скорее в следующем: ВВ>1. Что понимается вообще под _ссылкой_ на метод (и на свойство в частности)? Мне это не очень ясно.
А что такое вообще — ссылка? В дотнете любая переменная ссылочного типа — уже ссылка (масло маслянное). Т.е. ссылка — это способ некоего коссвенного обращения к чему-либо.
Применительно к методам — это некоторый унифицированный адаптер, позволяющий единообразно обращаться к любому методу с подходящей сигнатурой. Делегат — вполне себе ссылка на метод экземпляра (или просто статический метод). Я понимаю, что на оное понятие не натягивается ссылка из С++, давай предположим, что физическое представление ссылки — это необязательно группа байт размером в адресную шину. Для делегата представление ссылки — это не только данные (ссылка на целевой объект), но и код, адаптирующий вызов конкретного метода
ВВ>Более того сдается мне что делегат это совсем не ссылка.
Почему? По целям/задачам/функциональности — похож...
ВВ>2. Указатель на свойство создать вполне можно, хотя и используя менее удобный синтаксис чем в случае с обычным методом.
Как? Мож я чего-то упустил? Или все-таки через PropertyInfo?
Re: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, GlebZ, Вы писали:
GZ>И это плохо, что нельзя.
Естественно плохо. Сделать такое в принципе можно, но тогда все ссылки тормозить начнут. Так что невозможность передачи свойства по ссылке — это просто решение в пользу производительности.
Re[2]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, vdimas, Вы писали:
V>А через CreateDelegate — это надо PropertyInfo подавать, а получать его через рефлекшен, в общем статическая безопасность и типизация идет лесом... так же как и рефакторинг впоследствии...
Можно по typeof от подходящего делегата.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, GlebZ, Вы писали:
VD>Если бы ты еще за одно разобрался что такое лямбды и как они капеллируют с делегатами, то не говорил бы таких глупостей.
пардон, что лямбды делают с делегатами ?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[9]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Учитывая что свойство это в сущности обычный метод, что ты в данном случае понимаешь под передачей метода по ссылке? Нечто подобное в принципе предоставляет delegate
Свойство — это, очень часто, два метода.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, stalcer, Вы писали:
S>Естественно плохо. Сделать такое в принципе можно, но тогда все ссылки тормозить начнут. Так что невозможность передачи свойства по ссылке — это просто решение в пользу производительности.
Это еще почему?
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, GlebZ, Вы писали:
VD>>Если бы ты еще за одно разобрался что такое лямбды и как они капеллируют с делегатами, то не говорил бы таких глупостей. GZ>В терминах языка. Есть лямбда. Есть делегат. Есть анонимный метод.
Ага. В терминах, есть. Вот только анонимный метод и лямда это одно, а делегат совсем другое. Не жужно путать функцию не имеющую имени и средство позволяющее сослаться на них или на именованный метод.
VD>>Лямбды это замена действительно избыточному синтаксису анонимных методов, а делегаты это то через что ссылку на этот самый анонимный метод (лямду или на обычный метод) можно передать в функцию или поместить в поле. GZ>Именно это я и имел ввиду. Синтаксис делегатов(не анонимов и не лямбд) мне кажется слишком сложным а эффективность не очень.
Я не знаю, что ты пытался иметь в виду, но получилась ерунда. Ну, а что там тебе не нравится в "синтаксисе делегатов" вообще осталось не ясным. Не ясен даже сам термин "синтаксис делегатов".
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>1. Лямбды — это не просто делегаты.
Ага. Это вовсе не делегаты.
GZ> Лямбды это отдельные скрытые объекты.
Ну, делегаты это действительно объекты. А вот лямбды, как бы есть абстракция безымянного метода позволяющего делать или не делать синтаксические замыкания на контекст методов в которые они вложены. Никакой реализации это не определяет. Что же касается реализации в дотнете, то она бывает разная. Когда действительно создается скрытый объект, а когда всего лишь создается скрытй метод. Причем ничто не мешает в будущем изменить это поведение. Например, нет особых проблем заинлайнить передачу ссылки на лямбду и вообще избавиться от необходимости создавать какие-то методы или классы.
GZ>2. Знаешь что самое интересное.
Да все твои слова про делегаты так интересны, что я даже предположить боюсь.
GZ> У лямбд больше возможностей чем у простых делегатов.
Ага. А полей больше чем ссылок на неих.
GZ> Лямбды, в некоторой степени, более подходят под определения функций высшего порядка как это сделано в Lisp или SML, которых можно уточнять.
Во как? А мужики то и не знали (с). Ты определение функции высшего порядка то знашь? Понимаш ли, любая функция принимающая делагат еею является. Лбда же в Шарпе — это просто анонимный метод. И к функциям высшего порядка он имеет отношение только если сам принимает или возрващает функцию.
GZ> Вот если бы это было сделано явно для делегатов и в более простой манере, как это делается у функциональщиков.
Что сделано?
VD>>Лямбды это замена действительно избыточному синтаксису анонимных методов, GZ>Именно это и имелось ввиду.
Что имелось в виду? Ты почитай что ты пишешь? Ты препутал все на свете и несешь натуральную ахинею. Или так выражашь свои мысли, что тебя просто невозможно понять.
Запомни на будущее. Делегат — это ссылка на метод. Лямбда и анонимные методы — это методы не имеющие имени которые можно объявлять внутри других методов или в местах инициализации делегатов. Ссылаются на лмбду через делегат, но сама лямба оным не яявляется.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nose, Вы писали:
N>пардон, что лямбды делают с делегатами ?
То же что и любые другие методы — что хатят.
Лямбда == новый синтаксис для анонимных методов.
Анонимные методы — это метода не имеющие имени и которые можно обявлять внутри других методов или в месте инициализации делегатов.
Делегат — это ссылка на любой, в том числе и на анонимый, метод.
Единственная связь между делегатом и лямбдой — то то что она объявляется всегда в том месте где требуется делегат, так как на нее можно сослаться только по средствам делегата. Однако лямбда != делегат.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это правильно только в том случае, если речь идёт о закрытых полях.
Создание публичных полей в объектах уже нарушает инкапсуляцию.
ГВ>Нарушение же инкапсуляции состоит в самом по себе открытии поля объекта, неуместном открытии, разумеется.
Согласен, но тем не менее возможность получения ссылки на внтрении поял объекта может привести к нарушению инкапсуляции и без создания публичных полей. По этому предлагаемая механика передачи свойств по ссылке является абсурдом.
Т.е. я пытался объяснить товарищам почему поля не тоже самое что свойства.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Внимательнее Влад. Здесь подразумевается свойство, то есть проперть. Никакого нарушения
Я понимаю. О том тебе и говорю. Ты несешь околесицу. Предача свойства по ссыле — это абсурд! Вместо ссылка на свойство можно передать один/два делегата или некий объект-обертку.
Ссылка это фактически типизированный указатель на память повзоялющий менять эту память.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, Воронков Василий, Вы писали:
ВВ>1. Что понимается вообще под _ссылкой_ на метод (и на свойство в частности)? Мне это не очень ясно. Более того сдается мне что делегат это совсем не ссылка.
+1
ВВ>2. Указатель на свойство создать вполне можно, хотя и используя менее удобный синтаксис чем в случае с обычным методом.
-1
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, vdimas, Вы писали:
V>Блин, хотел по-быстрому накатать ссылку на св-во как объект (С# struct) из пары делегатов и переопределенного оператора implicit().
А приведение типов то тут зачем?
V>Однако, компилятор ругается на такой синтаксис: V>
V>PropRef<int> pr = new PropRef<int>(p1.get_P1, p1.set_P1);
V>
V>
V>Error 1 'ConsoleApplication1.Probe1.P1.get': cannot explicitly call operator or accessor
V>Блин, нельзя обратиться напрямую к акцессорам!
V>А через CreateDelegate — это надо PropertyInfo подавать, а получать его через рефлекшен, в общем статическая безопасность и типизация идет лесом... так же как и рефакторинг впоследствии...
V>А счастье было так близко...
Да сделать то это можно. Толко подключние будет в ранмайме:
using System;
class PropertyHolder<T>
{
private delegate T Getter();
private delegate void Setter(T value);
public PropertyHolder(object obj, string propertyName)
{
try
{
_getter = (Getter)Delegate.CreateDelegate(
typeof(Getter), obj, "get_" + propertyName);
}
catch (ArgumentException ex)
{
throw new ArgumentException(
"Неудается подключить PropertyHolder к getter-у свойства "
+ propertyName, "propertyName", ex);
}
try
{
_setter = (Setter)Delegate.CreateDelegate(
typeof(Setter), obj, "set_" + propertyName);
}
catch (ArgumentException ex)
{
throw new ArgumentException(
"Неудается подключить PropertyHolder к setter-у свойства "
+ propertyName, "propertyName", ex);
}
}
private Getter _getter;
private Setter _setter;
public T Property
{
get { return _getter(); }
set { _setter(value); }
}
}
class A
{
private int myVar = 10;
public int MyProperty
{
get { return myVar; }
set { myVar = value; }
}
}
class Program
{
static void Main()
{
PropertyHolder<int> holder1 = new PropertyHolder<int>(new A(), "MyProperty");
Console.WriteLine(holder1.Property);
holder1.Property++;
Console.WriteLine(holder1.Property);
}
}
Вот только зачем это нужно? Хоть раз в жизни бы такое потребовалось? Нафига нужно искуство ради искуства?
Это ведь все равно будет не ссылк, а объект посредник. Ссылка то будет на сам объект. А свойство точно так же будет вызваться как и раньше. Проще тогда или ввести интерфейс или просто пользоваться исходным объектом.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, stalcer, Вы писали:
S>Естественно плохо. Сделать такое в принципе можно, но тогда все ссылки тормозить начнут. Так что невозможность передачи свойства по ссылке — это просто решение в пользу производительности.
Блни, сегодня что магнитные бури? Ну, как можно передать сылку на два метода? Тут только объект-посредник поможет. Но это не ссылка! Или тогда что по вашему означет "ссылка"?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Хорошо ли, что свойство нельзя передать по ссылке
?
Если нам не помогут, то мы тоже никого не пощадим.
