Hi William,

I've seen your last commit about CAN libs (BTW it won't wake up buildbot
because I've updated yesterday and wasn't listening).
I've seen this lib: include/external/can/mcp2515.jal

This lib has to be prefixed by the type of part it is about. JSG says:

"""

 - <device-family>_<device>.jal for external libraries. device-family
describes the device family (...), and is often the directory name where the
lib is. device precisely sets the part.

Ex: lcd_hd44780_4.jal, rtc_ds1302.jal, co2_t6603.jal

"""

So I'd suggest to rename it (svn rename) to "can_mcp2515.jal". When it's
included in packages, where all libs are flatten (no more "can" directory),
users instantly see what this is about.


Now about naming convention of the content. JSG is quite fuzzy about this.
This idea here is deal with the question: what if there's another CAN lib
handling another part ? Will there be any collisions ? Sometime this is by
design (serial libs), sometime it must be avoided.

"""

All external names (of global variables, constants, procedures and functions
available to application programs) must start with a prefix unique to the
library. Names of other global entities (not supposed being used by
application programs) should use this prefix and use an additional
underscore at the beginning.

Variables, constants, procedures and functions must be named as:

 - <device>_<whatever> if you want to avoid namespace collision
 - <device-family>_<whatever> if you want to have a common API

"""

Read section "Constants, variables, procedures, functions" for more and for
examples.

So, does it make sense to have multiple CAN via multiple parts ? If so, you
should prefix with "mcp2515_".  If the purpose is to be able to choose
another lib like this one, but for another part, without changing client
code, then API shouldn't be mcp2515 specific. Still you'll have to prefix
with "can_" (this is what's been done for proc & func, but must also be done
for const & var).


Ex:

const REC = 0x1D

is little bit short, and may collide with a lib handling record (!), where
"REC" would an action code for instance.

const CAN_REC = 0x1D

makes it more specific. Kind of "namespaces by syntax"...



Cheers,
Seb
--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to