Bug 518 - Constructing objects from a TypeId seems complex
: Constructing objects from a TypeId seems complex
Status: RESOLVED INVALID
: ns-3
simulation core
: ns-3-dev
: All All
: P5 enhancement
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-03-09 10:33 EDT by
Modified: 2009-03-10 07:16 EDT (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-03-09 10:33:07 EDT
From the code I am writing:

void AddWimetronetStack (Ptr<Node> node, NodeId nodeId, TypeId
terminalMobility)
{
[...]
      terminalMobilityStrategy = Ptr<wmrp::TerminalMobilityStrategy>
(dynamic_cast<wmrp::TerminalMobilityStrategy*> (terminalMobility.GetConstructor
()()), false);
[...]

So, given a TypeId, creating an object of that typeid seems rather more complex
than the average NS-3 programmer will be able to discern.  Good thing I am not
an average programmer, but I feel sorry for the poor souls that will need to do
this too :-)

A good candidate for a better API could be (for example):

Ptr<T> TypeId::CreateObject () const;
------- Comment #1 From 2009-03-09 13:15:26 EDT -------
ObjectFactory::SetTypeId (...);
ObjectFactory::CreateObject<> (...);

The above API could be improved probably but I think it is fairly close to what
you want. I am going to mark this bug as invalid unless you add more context.
------- Comment #2 From 2009-03-09 13:27:49 EDT -------
I did have the feeling I was missing something... :-)

Still, it would be nice to construct an object directly from a TypeId.  It's
how e.g. Python works: you call the type and as result you get an instance of
that type.  It's rather uncomplicated.
------- Comment #3 From 2009-03-09 15:00:42 EDT -------
(In reply to comment #2)
> I did have the feeling I was missing something... :-)
> 
> Still, it would be nice to construct an object directly from a TypeId.  It's
> how e.g. Python works: you call the type and as result you get an instance of
> that type.  It's rather uncomplicated.

The main reason why this is not so is that a TypeId can represent anything
which derives from ObjectBase while ObjectFactory can only create objects which
derive from Object.
------- Comment #4 From 2009-03-09 15:06:30 EDT -------
(In reply to comment #3)
> (In reply to comment #2)
> > I did have the feeling I was missing something... :-)
> > 
> > Still, it would be nice to construct an object directly from a TypeId.  It's
> > how e.g. Python works: you call the type and as result you get an instance of
> > that type.  It's rather uncomplicated.
> 
> The main reason why this is not so is that a TypeId can represent anything
> which derives from ObjectBase while ObjectFactory can only create objects which
> derive from Object.

I don't see how one thing invalidates the other:

   Ptr<T> TypeId::operator() const;

This is type agnostic; can build anything that is reference countable ;-)
------- Comment #5 From 2009-03-09 15:15:18 EDT -------
(In reply to comment #4)
> > The main reason why this is not so is that a TypeId can represent anything
> > which derives from ObjectBase while ObjectFactory can only create objects which
> > derive from Object.
> 
> I don't see how one thing invalidates the other:
> 
>    Ptr<T> TypeId::operator() const;
> 
> This is type agnostic; can build anything that is reference countable ;-)

ObjectBase is not reference countable, hence, my earlier comment.
------- Comment #6 From 2009-03-10 07:16:52 EDT -------
(In reply to comment #5)
> ObjectBase is not reference countable, hence, my earlier comment.

Oh.. I had not noticed it.

Probably "Ptr<T> TypeId::CreateObject () const;" would still work in spite of
this.  But to preserve the layering logic, I give up on this.