Поделитесь личным опытом, добавляете ли вы методы классам в рантайме?.
Если да, то зачем?.
Из каких соображений вы выбрали этот вариант?. Как решаете проблему появляющейся запутанности?.
я тут решил использовать xmpppy для работы с жаббером, и там как используется такой подход к проектированию.. там есть класс Client, который умеет подключаться, но не умеет передавать какие либо данные.. за это отвечает другой класс, от которого при удачном коннекте пересаживаются методы клиенту..
проблема в том, что до начала использования по pydoc-у не понять схему работы приложения..
а единственная причина делать именно так мне видится только в том, что не надо на все методы отправки и т.п. вешать проверки наличия коннекта.. как бы до коннекта такого функционала нет и все попытки использования будут приводить к ошибке доступа к несуществующему методу..
Здравствуйте, neFormal, Вы писали:
F>Поделитесь личным опытом, добавляете ли вы методы классам в рантайме?.
F>Если да, то зачем?. Из каких соображений вы выбрали этот вариант?. Как решаете проблему появляющейся запутанности?.
F>я тут решил использовать xmpppy для работы с жаббером, и там как используется такой подход к проектированию.. там есть класс Client, который умеет подключаться, но не умеет передавать какие либо данные.. за это отвечает другой класс, от которого при удачном коннекте пересаживаются методы клиенту..
F>проблема в том, что до начала использования по pydoc-у не понять схему работы приложения..
F>а единственная причина делать именно так мне видится только в том, что не надо на все методы отправки и т.п. вешать проверки наличия коннекта.. как бы до коннекта такого функционала нет и все попытки использования будут приводить к ошибке доступа к несуществующему методу..
По-моему поделить сущности гораздо логичней, т.е. что-нибудь аля
protocol = choose_protocol()
protocol.extra_init(protocol_args)
connection = protocol.open(connection_args)
connection.some_method()
Здравствуйте, neFormal, Вы писали:
F>Поделитесь личным опытом, добавляете ли вы методы классам в рантайме?.
F>Если да, то зачем?. Из каких соображений вы выбрали этот вариант?. Как решаете проблему появляющейся запутанности?.
Запутанности нет если знаешь что делаешь.
Это все называется dynamic mix-in :
http://www.linuxjournal.com/node/4540/print
В умелых руках достаточно мощное средство.
F>а единственная причина делать именно так мне видится только в том, что не надо на все методы отправки и т.п. вешать проверки наличия коннекта.. как бы до коннекта такого функционала нет и все попытки использования будут приводить к ошибке доступа к несуществующему методу..
Одна из причин использования данной техники в повышении эффективности исполняемого кода в языках питоновской группы.
Поиск методов осуществляется по цепочке прототипов (классов) в runtime. Т.е. чем ближе vtbl с методом к this тем поиск эффективнее.
Здравствуйте, c-smile, Вы писали:
F>>Поделитесь личным опытом, добавляете ли вы методы классам в рантайме?.
F>>Если да, то зачем?. Из каких соображений вы выбрали этот вариант?. Как решаете проблему появляющейся запутанности?.
CS>Это все называется dynamic mix-in : http://www.linuxjournal.com/node/4540/print
CS>В умелых руках достаточно мощное средство.
CS>Запутанности нет если знаешь что делаешь.
это всё понятно..
самому в своём коде запутаться сложно..
я имел в виду, что остальные кодеры получат интерфейс, который колеблется в зависимости от действий.. т.е. другие возможно будут путаться..
CS>Одна из причин использования данной техники в повышении эффективности исполняемого кода в языках питоновской группы.
CS>Поиск методов осуществляется по цепочке прототипов (классов) в runtime. Т.е. чем ближе vtbl с методом к this тем поиск эффективнее.
да, тоже вариант..
интересно только, когда это начнут использовать повсеместно и когда начнутся истерики по этому поводу?.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, c-smile, Вы писали:
F>>>Поделитесь личным опытом, добавляете ли вы методы классам в рантайме?.
F>>>Если да, то зачем?. Из каких соображений вы выбрали этот вариант?. Как решаете проблему появляющейся запутанности?.
CS>>Это все называется dynamic mix-in : http://www.linuxjournal.com/node/4540/print
CS>>В умелых руках достаточно мощное средство.
CS>>Запутанности нет если знаешь что делаешь.
F>это всё понятно..
F>самому в своём коде запутаться сложно.. я имел в виду, что остальные кодеры получат интерфейс, который колеблется в зависимости от действий.. т.е. другие возможно будут путаться..
Это смотря как объяснишь.
В Sciter например DOM элемент в зависимости от значения DOM атрибута может иметь разные наборы методов.
input#some[mode="first"]
{
prototype: FirstClass;
}
input#some[mode="second"]
{
prototype: SecondClass;
}
Т.е. вообще быть instance разных классов в разные моменты времени.
Вроде как ни у кого такая ситуация вопросов не возбуждает.
Скорее наоборот — пользительная фича.
CS>>Одна из причин использования данной техники в повышении эффективности исполняемого кода в языках питоновской группы.
CS>>Поиск методов осуществляется по цепочке прототипов (классов) в runtime. Т.е. чем ближе vtbl с методом к this тем поиск эффективнее.
F>да, тоже вариант..
F>интересно только, когда это начнут использовать повсеместно и когда начнутся истерики по этому поводу?.
Да ну уж истерики... всякие там jQuery и prototype.js делают такие трюки направо и налево. А ёжики вооружившись альпенштоками всё штурмуют молча тот кактус.