RE: Named events

Philip,

Your sc_event_object is an excellent implementation of the Cadence proposal for sure. Whether it needs to be included in the standard is the question.

What it buys the user is that he can make one API call sc_find_object() and be able to find all the named entities, instead of having to make two API calls: sc_find_object() and sc_find_event().

Beyond that, user still needs to be conscious that events are "special", and he needs to call the get_event() API, etc. as you point out.

You say at the end

"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."

My vote would be to treat the sc_event_object class as an implementation detail, not mentioned in the LRM.

BTW, there is one API that I would like to steal from your proposal below (I missed this in the Cadence proposal).

  sc_object* sc_event::get_parent_object() const;

About the sc_named_event class, I'm not in favor of it. I feel it is non-intuitive for user to use this class instead of the familiar sc_event class, and not obvious when to use which class.

Another clarification to Cadence proposal:

Only the events that are hierarchically named and added to global object-event namespace end up being added to parent scope and can be retrieved by get_child_objects() API. These include all static events, all dynamic explicitly named events and may or may not include dynamic not-explicitly-named events (implementation dependent).

Thanks,
-Bishnupriya

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Wednesday, November 17, 2010 2:56 AM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; P1666 Technical WG
Subject: 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.