On 08/11/2016 05:25 PM, Ed Leafe wrote:
On Aug 3, 2016, at 6:47 PM, Jay Pipes <jaypi...@gmail.com> wrote:
Please see the README for examples of how the library works and how I'm
thinking of structuring these capability strings and symbols. I intend
os-capabilities to be the place where the OpenStack community catalogs and
collates standardized features for hardware, devices, networks, storage,
hypervisors, etc.
Overall this looks good, although it seems a bit odd to have ALL_CAPS_STRINGS
to represent all:caps:strings throughout.
ALL_CAPS is generally used for constant symbols in many (most?)
programming languages, AFAIK.
The example you gave:
print os_caps.HW_CPU_X86_SSE42
hw:cpu:x86:sse42
begs the question: is the rule going to be that capability for any constant
will always be: CONST.lower().replace(“_”, “:”) ? If so, I’m not sure I see how
the capabilities are not themselves constants.
Because you can make a typo with a string and it can go unnoticed. A
typo in a constant means the code won't compile/import because of an
unknown symbol.
That's the reason for having these strings represented as constant
symbols in a shared library.
The namespacing is ugly, but I guess it’s necessary given that names are not
simple tags, but nested data structures in string form.
Yeah, it's ugly-ish. I'm certainly open to suggestions for how to better
nest/represent these groups of capability constants.
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
