[Tinyos-help] TinyOS Design Questions - (Question-1)

[Faisal Aslam]

Thank you. Now your solution will work. However, I am not sure what you 
mean by this line though "/This should work if the *provider* of the 
interface implements the default handlers for the event/".

Furthermore, it is not necessary bad design always when you have such a 
problems.
For example:
when using printf utility I normally do not care about 
PrintfControl.stopDone, PrintfControl.flushDone events but they have to 
be implemented always with "empty" bodies. Similarly,
when I have not called command AMControl.stop(...) then why I have to 
implement event void AMControl.stopDone(error_t err). Similarly there 
are many other such examples.


In an ideal scenario, one should only worry about implementing events 
whose relavent command he has called. Like if I call AMControl.stop() 
then I think about implementing AMControl.stopDone event otherwise not. 
Furthermore, in an ideal scenario one should also allow to register his 
interest in events and ignore other events. I mean something similar to 
the idea defined in Observer design Pattern.

I have to think if that will be a good design to always provide bloated 
interfaces when you are working on a big project and using many 
interfaces. May be simple change in design of NesC could simply remove 
this problem?  I wish to have some cleaner/better solution. I agree that 
this problem will exist anywhere (like Java) when you will be using 
interface. However in NesC this problem aggravates a great deal because 
you only allow interacting using interfaces (no inheritance etc).

regards,
Faisal


Janos Sallai wrote:
>> Problem:- In NesC if I have to use a single command of an interface then
>> I have to implement ALL of its event. Even though, I am not interested
>> in any one of those events. Those empty functions with nothing in them
>> make a programmers code cumbersome for no reason. May be you do not find
>> it a problem but being a programmer I really find it annoying.
>>     
>
> You can wire the functions one by one, i.e. if you use only one function
> (command or event) of an interface, you can wire just that function, not
> the whole interface. This should work if the provider of the interface
> implements the default handlers for the event.
>
> Alternatively, if it's a recurrent problem, you can also create a glue
> component that uses the bloated interface, defines the "empty functions"
> and provides a slim interface.
>
> Furthermore, if it's a recurrent problem, the issue might be that it's a
> bad interface design. Typically, if you call a command, you'll want to
> know when the corresponding operation completes, so you'll need to handle
> the completion event.
>
> Janos
>