Здравствуйте, VladD2, Вы писали:
VD>Извини, но это глупость. Они в принципе разные! У них только синтаксис похож. Попробуй передать свойство по ссылке.
И это плохо, что нельзя.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, VladD2, Вы писали:
VD>>Извини, но это глупость. Они в принципе разные! У них только синтаксис похож. Попробуй передать свойство по ссылке. GZ>И это плохо, что нельзя.
Учитывая что свойство это в сущности обычный метод, что ты в данном случае понимаешь под передачей метода по ссылке? Нечто подобное в принципе предоставляет delegate
Re[9]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Учитывая что свойство это в сущности обычный метод, что ты в данном случае понимаешь под передачей метода по ссылке? Нечто подобное в принципе предоставляет delegate
Обычный метод? И как его вызвать без рефлекшона простому индийцу?
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, GlebZ, Вы писали:
ВВ>>Учитывая что свойство это в сущности обычный метод, что ты в данном случае понимаешь под передачей метода по ссылке? Нечто подобное в принципе предоставляет delegate GZ>Обычный метод? И как его вызвать без рефлекшона простому индийцу?
Ну а во вторых, сами делегаты штука неудобная и нудная. Лямбды не зря начали вводить.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, GlebZ, Вы писали: GZ>Обычный метод? И как его вызвать без рефлекшона простому индийцу?
Тот факт, что компилятор скрывает от нас его, еще не делает метод необычным Скажем, если объявить на MC++ свойство с параметрами, то из С# его можно (и нужно) будет вызывать через set_XXX.
То, о чем говорит, Василий -- в код, работающий с ссылками (т.е. с managed pointerами в терминологии MSIL), нельзя передать свойство -- по крайней мере в текущей реализации виртуальной машины.
Можно, конечно, пойти на хитрость -- если передача свойства по ссылке происходит, то завести локальную переменную, скопировать туда значение, вызвать метод, а потом вызвать setter. Но это путь очень опасный, т.к. свойства могут иметь весьма нетривиальные зависимости между собой.
Re[10]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, Mab, Вы писали:
GZ>>Обычный метод? И как его вызвать без рефлекшона простому индийцу? Mab>Тот факт, что компилятор скрывает от нас его, еще не делает метод необычным Скажем, если объявить на MC++ свойство с параметрами, то из С# его можно (и нужно) будет вызывать через set_XXX.
Ага. А операции в VB через реализовывать через op. Одно дело язык, другое подпорки.
Mab>То, о чем говорит, Василий -- в код, работающий с ссылками (т.е. с managed pointerами в терминологии MSIL), нельзя передать свойство -- по крайней мере в текущей реализации виртуальной машины.
Да все можно Вопрос насколько хакерские методы будут использоваться. Делегаты и рефлекшон ведь действительно хаком не назовешь.
Недавно сделал вывод, если ты встретил то чего нельзя сделать, значит ты плохо знаешь namespace Emit.
Mab>Можно, конечно, пойти на хитрость -- если передача свойства по ссылке происходит, то завести локальную переменную, скопировать туда значение, вызвать метод, а потом вызвать setter. Но это путь очень опасный, т.к. свойства могут иметь весьма нетривиальные зависимости между собой.
Я вообще-то в действительности имел ввиду именно указатель на функцию как функциональный тип. То есть взял ссылку на свойство или метод, и присвоил куда-то. А вот в это куда-то уже думают что с этим делать. С делегатами получается еще та песня. Ну жутко неудобно и тормозно.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Хорошо ли, что свойство нельзя передать по ссылке
Здравствуйте, Воронков Василий, Вы писали:
GZ>>Обычный метод? И как его вызвать без рефлекшона простому индийцу?
ВВ>Delegate.CreateDelegate — надеюсь простой индус догадается реальное название метода указать?
Обломс. Думал что он затрагивает рефлекшон. Ан нет. Хотя и проверки нехилые при создании но работает не через reflection.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Хорошо ли, что свойство нельзя передать по ссылке
GZ>Да все можно
Как именно?
GZ>Вопрос насколько хакерские методы будут использоваться. Делегаты и рефлекшон ведь действительно хаком не назовешь. GZ>Недавно сделал вывод, если ты встретил то чего нельзя сделать, значит ты плохо знаешь namespace Emit.
Боюсь, одним эмитом тут не обойтись. Придется как минимум изучать IL-код существующих методов, получающих ссылки, и генерировать новый, работающий со свойством. В общем, ерунда какая-то.
Mab>>Можно, конечно, пойти на хитрость -- если передача свойства по ссылке происходит, то завести локальную переменную, скопировать туда значение, вызвать метод, а потом вызвать setter. Но это путь очень опасный, т.к. свойства могут иметь весьма нетривиальные зависимости между собой. GZ>Я вообще-то в действительности имел ввиду именно указатель на функцию как функциональный тип. То есть взял ссылку на свойство или метод, и присвоил куда-то. А вот в это куда-то уже думают что с этим делать. С делегатами получается еще та песня. Ну жутко неудобно и тормозно.
1. Не очень понял, чем именно делегаты не устроили. То, что нельзя напрямую создать делегат для сеттера -- это ограничение C#, а никак не платформы.
2. Скорость вызова делегата по порядку величины сопоставима с вызовом виртуального метода. Не слишком быстро, но жить можно.
Здравствуйте, GlebZ, Вы писали:
VD>>Извини, но это глупость. Они в принципе разные! У них только синтаксис похож. Попробуй передать свойство по ссылке. GZ>И это плохо, что нельзя.
Курите ООП и инкапсуляцию, сударь.
Понимаеш ли, если передать ссылку на поле объекта, то ты уже не сможешь гарантировать, что состояние твоего объекта не будет нарушено внешними действями.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну а во вторых, сами делегаты штука неудобная и нудная. Лямбды не зря начали вводить.
Если бы ты еще за одно разобрался что такое лямбды и как они капеллируют с делегатами, то не говорил бы таких глупостей.
Лямбды это замена действительно избыточному синтаксису анонимных методов, а делегаты это то через что ссылку на этот самый анонимный метод (лямду или на обычный метод) можно передать в функцию или поместить в поле.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mab, Вы писали:
Mab>Можно, конечно, пойти на хитрость -- если передача свойства по ссылке происходит, то завести локальную переменную, скопировать туда значение, вызвать метод, а потом вызвать setter. Но это путь очень опасный, т.к. свойства могут иметь весьма нетривиальные зависимости между собой.
И это правильно, так как не нарушет инкамсуляции объекта. Точно так же правильно пользоваться делегатами для установки или считывания свойств, так как это тоже не нарушает инкапусляции. А вот передавать ссылки на поля — это грубейшее нарушение инкапсуляции и слава богу, что его в дотнете нет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
ВВ>>Delegate.CreateDelegate — надеюсь простой индус догадается реальное название метода указать? GZ>Обломс. Думал что он затрагивает рефлекшон. Ан нет. Хотя и проверки нехилые при создании но работает не через reflection.
Чуть-чуть захватывает. На время создания делегата. Но дальше получается прямой делегат приводящий к вазову сеттера или геттера свойства. Так что проблем с производительностью тут не будет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Извини, но это глупость. Они в принципе разные! У них только синтаксис похож. Попробуй передать свойство по ссылке. GZ>>И это плохо, что нельзя.
VD>Курити ООП и инкапсуляцию, сударь.
VD>Понимаеш ли, если передать ссылку на поле объекта, то ты уже не сможешь гарантировать, что состояние твоего объекта не будет нарушено внешними действями.
Внимательнее Влад. Здесь подразумевается свойство, то есть проперть. Никакого нарушения
Здравствуйте, VladD2, Вы писали:
GZ>>Ну а во вторых, сами делегаты штука неудобная и нудная. Лямбды не зря начали вводить. VD>Если бы ты еще за одно разобрался что такое лямбды и как они капеллируют с делегатами, то не говорил бы таких глупостей.
В терминах языка. Есть лямбда. Есть делегат. Есть анонимный метод.
VD>Лямбды это замена действительно избыточному синтаксису анонимных методов, а делегаты это то через что ссылку на этот самый анонимный метод (лямду или на обычный метод) можно передать в функцию или поместить в поле.
Именно это я и имел ввиду. Синтаксис делегатов(не анонимов и не лямбд) мне кажется слишком сложным а эффективность не очень.
Здравствуйте, GlebZ, Вы писали:
GZ>Именно это я и имел ввиду. Синтаксис делегатов(не анонимов и не лямбд) мне кажется слишком сложным а эффективность не очень.
Вот-вот, и как раз напрашивается риторический вопрос: почему делегаты не стали распространённым явлением в программах на C++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
Mab>>Можно, конечно, пойти на хитрость -- если передача свойства по ссылке происходит, то завести локальную переменную, скопировать туда значение, вызвать метод, а потом вызвать setter. Но это путь очень опасный, т.к. свойства могут иметь весьма нетривиальные зависимости между собой.
VD>И это правильно, так как не нарушет инкамсуляции объекта. [...] А вот передавать ссылки на поля — это грубейшее нарушение инкапсуляции [...]
Это правильно только в том случае, если речь идёт о закрытых полях. Нарушение же инкапсуляции состоит в самом по себе открытии поля объекта, неуместном открытии, разумеется.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mab, Вы писали:
Mab>1. Не очень понял, чем именно делегаты не устроили. То, что нельзя напрямую создать делегат для сеттера -- это ограничение C#, а никак не платформы.
На заголовок посмотри. Mab>2. Скорость вызова делегата по порядку величины сопоставима с вызовом виртуального метода. Не слишком быстро, но жить можно.
Виртуальный метод быстрее. Хотя бы потому что он зачастую оптимизируется в простой(в отличие от того же делегата). Делегат в алгоритм с высокой повторяемостью помещать надо с опаской.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, GlebZ, Вы писали:
GZ>>Ну а во вторых, сами делегаты штука неудобная и нудная. Лямбды не зря начали вводить.
VD>Если бы ты еще за одно разобрался что такое лямбды и как они капеллируют с делегатами, то не говорил бы таких глупостей.
1. Лямбды — это не просто делегаты. Лямбды это отдельные скрытые объекты.
2. Знаешь что самое интересное. У лямбд больше возможностей чем у простых делегатов. Лямбды, в некоторой степени, более подходят под определения функций высшего порядка как это сделано в Lisp или SML, которых можно уточнять. Вот если бы это было сделано явно для делегатов и в более простой манере, как это делается у функциональщиков.
VD>Лямбды это замена действительно избыточному синтаксису анонимных методов,
Именно это и имелось ввиду.
Здравствуйте, Геннадий Васильев, Вы писали:
GZ>>Именно это я и имел ввиду. Синтаксис делегатов(не анонимов и не лямбд) мне кажется слишком сложным а эффективность не очень. ГВ>Вот-вот, и как раз напрашивается риторический вопрос: почему делегаты не стали распространённым явлением в программах на C++.
Ну это кому как. Я пользую(правда не бустовые а свои). Тут вопрос только в реализации. В Net делегаты множественные, в результате прямой ссылки на функцию не долждешься. В С++ у меня все компилируется в простой вызов функции.
Что касается эффективности, то эффективности функциональных языков конечно ожидать не стоит. Но было бы хоть что-то.
