[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] TEP 102 overhauled

[Cory Sharp]

On 5/18/05, David Gay <dgay42 at gmail.com> wrote:
> On 5/18/05, Cory Sharp <cory.sharp at gmail.com> wrote:
> > * Most all *M.nc components have been renamed to *C.nc, irregardless
> > if they are configurations or modules.  This is the better naming
> > convention for abstracting away implementation files without causing
> > *C/*M file bloat.
> 
> Can we have a (hopefully brief) discussion on this aspect of our
> coding convention? I happen to agree with this view, but I was
> definitely outvoted last time round...
> 
> Pros for current C (config) and M (module) rule:
> - easy to tell from name where actual code (i.e., logic) is
> - if FooC was a module, and some change now requires it to use some
> external service (e.g., a timer), you don't suddenly have to make FooC
> into a configuration and create a new FooM
> 
> Pros for "C stands for public component":
> - avoids creating lots of configurations which just reflect a
> particular module (these are potentially  error-prone, annoying to
> write and clutter up the directories)
> 
> Note that I definitely think we should avoid the 1.x rule ("use C if
> you have a name clash with an interface, use M if you have a name
> clash with something ending in C")
> 
> David

I argued strongly for the "C for configuration, M for module, only
wire to C" camp last time.  I now repent my evil ways.  I too now see
benefits to both methods, and even lean in favor of the "C is for
public" camp.

It seems that "C is public" method still allows for "C is
configuration" method if the implementor so chooses.  The converse is
not true.  So I now vote "C is public".

Cory

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg