Поделитесь личным опытом, добавляете ли вы методы классам в рантайме?.
Если да, то зачем?. Из каких соображений вы выбрали этот вариант?. Как решаете проблему появляющейся запутанности?.

я тут решил использовать 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 делают такие трюки направо и налево. А ёжики вооружившись альпенштоками всё штурмуют молча тот кактус.