Re[12]: Замыкания
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.11 13:39
Оценка:
Здравствуйте, BogdanMart, Вы писали:

Z>> Gри небольшой модификации кода превратится в объект замыкания, ты даже не поймешь что произошло

BM>Я то пойму.. замікания шарю хорошо, да и не надо его менять. (но в целом самому создать метод надежнее, безусловно, так и сделал..)

Я согласен с Ziaw. Если ты хочешь надежной работы, то ссылку на лямбду которую ты хочешь поместить в "слабое событие" нужно "прникапывать" в поле того объекта который подписывается на событие. Иначе ничего гарантировать нельзя. Твой код будет зависеть от фазы луны и направления ветра. Рано или поздно у тебя начнутся глюки которые ты, возможно, даже не сможешь понять.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Замыкания
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.01.11 13:49
Оценка:
Здравствуйте, BogdanMart, Вы писали:

BM>Както по дебильному немерле генерит замыкания


Все генерируется верно. У тебя просто ошибка в коде:
BM>
BM>                      OnPropertyChanged((param.Name : string));
BM>


BM>2) Зачем вообще создавать класс _N__N_lambda__8057__8075, C# создает в таком случаае приватный метод с рандомным именем, и подписывает на событие делегат на этот метод.


Н1 генерирует функциональный объект при следующих условиях:
1. Функция используется как функция высшего порядка (ФВП) — это как раз твой случай.
2. Функция используется более одного раза и при этом она захватывает внешний контекст (создает замыкание).

К сожалению, компилятор Н1 иногда осторожничает и делает функциональным объектом то что можно было бы сделать методом. Это не доработка, но исправление ее осложнено тем, что код там очень мутный. В Н2 можно довести этот вопрос до совершенства.

BM>Я бы не возущался... но есть один нюанс, мы используем WeakDelegatе и по этому _N__N_lambda__8057__8075 запроста уберется сборщиком мусора... очень печально.


Ну, дык, как правильно тебе сказал Ziaw ты делаешь слишком смелые предположения (и на шарпе тоже). Работа твоего кода будет зависеть от фазы луны. Так что просто помести ссылку на лямбду в поле того объекта время жизни которого которого должно перекрывать время жизни лямбды.

BM>Это создавать целый метод для такой тривиальной задачи... а шарп справлялся...


Создание метода тоже не очень хорошее решение, так как код будет зависеть от реализации. Лучше просто сделай явную ссылку. Это стопроцентная гарантия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Замыкания
От: BogdanMart Украина  
Дата: 30.01.11 15:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Все генерируется верно. У тебя просто ошибка в коде:

BM>>
BM>>                      OnPropertyChanged((param.Name : string));
BM>>


Да, это я заметил:

BM>> Про замыкание для гуида вопрос снимаеться... забылся поставить $ перед (param.Name : string)

(первый ответ на пост)

Но в целом, да. Ты прав! как-то тупонул.
Re[5]: Замыкания
От: catbert  
Дата: 30.01.11 15:16
Оценка: +1
Здравствуйте, BogdanMart, Вы писали:

BM>Ну как-бы ситуация не очень ординарная, но с другой стороны с этими функциями перемудрили где-то. Можно было и по проще сделать первоклассные функции.


Проблемы производительности — это одно. Но если правильность вашего кода зависит от реализации компилятора, это уже другое, намного хуже.

Что будет с вашим кодом, если в Редмонде тоже решат, что "объекты быстрее делегатов" и изменят реализацию лямбд? Что будет, если вы захотите скомпилировать ваш код на Mono C#, где компилятор по-другому создает ламбды?

Я сомневаюсь (хотя чесно говоря, не смотрел), что в спецификации описано, как в C# создаются анонимные функции.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.