A thought on EvntIn(Src, EvntId)

I was working on MS ACCESS to create event call backs between objects and devised this function signature. After thinking it through, I decided that this is really not a good way of handling event call backs.

Here's my reasoning:

The appropriation of this function is arguable concerning the implementation of the EvntId, if the source is a class that implements ours and other interfaces. Under this situation, it is true that

we can cast the Src and pass it to our parent object. But casting the EvntId requests a lot from a programming language.

Suppose a class is implementing several interfaces which include specifications of enumerated event IDs. When calling this function, how can that class decide what event Id to use? In order to resolve this, one can require the EventId be stored in the object. But this will raise another problem: What if another event happens before this function got time to process the event? This will lead to the requirement that the calling class must LOCK the event Id for calling this function while still allow other process to update the event Id. This, again, request a lot from a computer language.

If a language implemented the event by calling different call back function and, therefore, eliminated the need for passing the event Id, the issue of casting the event Id will not exist. Also if a language includes the call-back registration as part of the interface specification, the syntax will be OK since the event triggering class knows how to cast EvntId be passed to the call-back function.

In light of this, this function can only be implemented as a internal hub function that called by all event call back functions.

As a related thoughts, a event issuing object should never implement a variable that record the event Id since the value will never stick and using that variable for anything is questionable - queuing events is a different issue.