RE: Named events

Bishnupriya, Philipp,

I have come round to Bisnupriya's way of thinking on this 8=)

I would add
        bool sc_name_exists(const char*) cont;
and
        sc_object* sc_event::get_parent_object() const;

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
Cc:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, P1666 Technical WG
<systemc-p1666-technical@eda.org>
Date:
17/11/2010 12:39
Subject:
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.