design decision: event sources

[Enrico Zini]

On Mon, Jan 14, 2008 at 10:35:08PM +0100, martin f krafft wrote:

> Events and event handlers are great, especially in asynchronous
> processing. However, an interface manipulator, such as
> IfaceManipPlain.add_ip_address would basically be a synchronous
> action. Instead of it raising an event and letting the event handler
> invoke the method to do the work on the interface, why not let the
> interface manipulator invoke the method directly?

Conceptually, raising an event and calling a function are the same
thing, just implemented differently.  Some programming environments even
refer to "invoking a function" as "sending a message".

The difference is on the implementation details, that is, what amount of
abstraction and coupling you need.  Do you need more than one subsystem
to react to the event, for example?

My suggestion is to start simple and then add complexity when needed.
Unless you see a reason to implement a function call in a complicated
way, implement it in an easy way: when you'll see the reason, you can
always refactor.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080115/e23cc0e0/attachment.pgp