On Sat, Sep 12, 2009 at 09:10:49AM +0200, Peter Soetens wrote:
> On Fri, Sep 11, 2009 at 16:45, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> Hi,
>
> I'm currently updating my Lua bindings to rtt-2.0-mainline in
> preparation for releasing these at last and came across the new
> Activity IF, which merges the NonPeriodicActivity and PeriodicActivity
> into one (good!). But still there are so many constructors:
>
> 1) Activity(base::RunnableInterface* r = 0, const std::string& name =
> "Activity" );
> 2) Activity(int priority, base::RunnableInterface* r = 0, const std::string
> & name ="Activity");
> 3) Activity(int priority, Seconds period, base::RunnableInterface* r = 0,
> const std::string& name ="Activity");
> 4) Activity(int scheduler, int priority, Seconds period,
> base::RunnableInterface* r = 0, const std::string& name ="Activity");
>
> couldn't these be replace by one single (number 3) ? This would make
> it easier for specifiying the binding glue code, but I also find it a
> lot moe readable and understandable.
>
>
> The 'number' refers to the number of use cases and has been discussed on this
> list. Backwards compatibility (s/PeriodicActivity/Activity/ and s/
> NonPeriodicActivity/Activity/) played also a role.

But does every use case necessarily require an own method, even if
they are redundant? WRT backwards compatibility, if you don't rid
yourself from old clutter for 2.0, when then?

> If the overloads are disturbing to your effort, you could always introduce
> factory functions in C++ with different names which in turn call the
> appropriate constructor.

Yes, thats what I'm doing, but it makes the syntax slightly
inconsistent, because then I need to use a function for creating the
object and only later can use methods.

> BTW, are you sure you want to expose the interface of Activity to lua ?

No :-) Possibly it's sufficient to use the deployer method.

Markus