On Dec 31, 2009, at 1:29 AM, Alex Leone wrote:

The only problem with the current implementation is that it isn't
possible to pass temporary data.  All that needs to be added to the
current code is to free the pdata pointer if it isn't null:

Yes... that is somewhat true, but only at the lowest level.
It's not the mechanism of *how* one passes data through that function, but the high-level "why" if that is even the correct approach to take.

We need to consider DBus, command-line, brand-new-yet-to-be-implemented extension API, etc.



1.  To trigger an action that passes data to the listeners:
void *pdata = malloc(sizeof(data_struct));
data_struct *d = (data_struct *)pdata;

Actually in C++ that is likely to have sever problems. If someone realizes that a struct is just a class, and tacks on a method... BOOOM!!!!

:-)

You need 
DataStruct *datum = new DataStruct(); // using 'new' is critical
...
DataStruct *d = static_cast<DataStruct*>(pdata); // need to use C++ explicit casts, not old C-style casts.
d->x0 = 4.0;
d->y0 = 5.5;
sp_perform_action(ACTION_EXPORT_AREA, d);
...


However taking yet another look, there is no need to "new" at all:

DataStruct data(4.0, 5.5);
sp_perform_action(ACTION_EXPORT_AREA, &data);


2.  sp_perform_action passes pdata to the listeners for the event,
casting pdata to (data_struct *).  If the listener needs to save some
of the data, it makes a local copy.
void action_export_area(..., void *pdata)
{
 data_struct *d = (data_struct *)pdata;

For proper C++ this should be

DataStruct *d = static_cast<DataStruct*>(pdata);


3.  After serving all the listeners, sp_perform_action calls free on pdata.

No need to free if it were on the stack. Also C++ should use new + delete and not malloc + free.


DBus is meant for data communication between processes.  It uses
strings to represent the format of the data that is being passed back
and forth.  This is way overkill for an event system in a single
application, because it's possible to pass around void pointers and
cast to the correct data structure in the handler.

yes...

But the point of the verb mechanism is to support generic functionality decoupled from the input source it came from. These include:

* User clicking in the GUI
* Command-line invoking functionality
* DBus invoked functionality
* Live extension invoked functionality.

Looking at the current command-line, we are hitting some problems because it is *not* using shared code. It does it's own thing and thus makes it hard to share advanced functionality (as you want) in a simple manner. We want to be sure to be moving *away* from that situation, and not more towards it.