Re: Named events

All,

I may have another option for naming events, which at least fixes the
separate, but magically connected namespace issue without sacrificing
the performance.

  Technically, the idea is to add a separate (and optional)
sc_event_object* member to sc_event, which is derived from sc_object and
is used for naming events. I'll try to draw a class diagram, hopefully
it works with all mail clients. Consider the following hierarchy:

  sc_object
     ^ +---------------------------+
     | | sc_event |
     | 0..1 +---------------------------+
sc_event_object ---- | sc_event_object* m_object |
      ^ +---------------------------+
      | ^
       \ ------+----------- /
               |
          sc_named_event (for convenience)

The behaviour would be the following:

  sc_event()
    Leaves the allocation of an sc_event_object to the implementation.
    The sc_event_object could stay NULL for dynamic, unnamed events.

  sc_event( const char* )
    Creates an sc_event_object with the requested name in the
    regular object hierarchy. No special rules needed.

  sc_object* sc_event::get_object() const // return placeholder
    { return m_object; }

  const char* sc_event::[base]name() const
    { return m_object ? m_object->[base]name() : NULL ; }

  sc_object* sc_event::get_parent_object() const
    { return m_object ? m_object->get_parent_object() : NULL ; }

  The sc_event_object class is only a placeholder in the object
hierarchy, technically implementation defined but with the following
additional interface:

  const char * sc_event_object::kind() const
    { return "sc_event"; }

  // return represented event (could also return a reference)
  sc_event * get_event()
  sc_event const * get_event() const

For convenience, an explicit sc_named_event (which always gets an
automatic name) could also be added:

class sc_named_event
  : public sc_event_object
  , public sc_event
{
public:

    sc_named_event();
    explicit sc_named_event( const char* name );
    ~sc_named_event();

    // disambiguate
    using sc_event_object::basename;
    using sc_event_object::name;
    using sc_event_object::kind;
    using sc_event_object::get_parent_object;
};

  With this proposal, events are optionally part of the regular
sc_object hierarchy via the placeholder sc_event_object instances.
Regular traversal and naming expectations hold. Performance should not
be impaired.

  I think, the only drawback would be the deviation in the conversion
during traversal. Usually, you can query for the kind() of an object
and do an appropriate dynamic_cast afterwards. With the above proposal,
you would need to do an get_event() to access the actual event instance:

  // somewhere in "top.m"
  sc_event ev1( "my_event" );
  sc_named_event ev2( "my_named_event" );

  sc_object* o1 = sc_find_object( "top.sub.my_event" );
  sc_object* o1 = sc_find_object( "top.sub.my_named_event" );

  // dynamic cast does not work for plain sc_event, need -> get_event()
  // sc_event * ep1 = dynamic_cast<sc_event*>(o1); // -> NULL
  sc_event * ep1 = dynamic_cast<sc_event_object*>(o1)->get_event();

  // for an sc_named_event, usual dynamic_cast would work fine
  sc_event * ep2 = dynamic_cast<sc_event*>(o2);

We could probably add corresponding get_child_events() functions that do
this filtering, of course. In that case, the sc_event_object could be
even more restricted to the internal use of the implementation.

Opinions? Could that be a working compromise?

Greetings from Oldenburg,
Philipp

NB: To avoid bouncing, I've snipped the previous discussion.

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.