#121 Add support for namespaces in database

Major Effort
open-accepted
nobody
Modeling (16)
9
2011-01-13
2011-01-13
Tom Browder
No

For my own use I have started using the attr feature to add a "{namespace} {Mantech}" attribute pair to the _GLOBAL object as well as other useful attributes. The namespace let's my TGM users know to expect certain attributes on objects, etc. For instance, old TGMs used material codes from PDAM or COVART. I use _GLOBAL to add an attribute pair "{material_codes} {COVART}" or ""{material_codes} {PDAM}" to let the user know what the material codes are. More modern practices use attributes on objects, e.g., "{MUVES_component}", and for our vulnerability tool VALUE on each region I use, e.g., "{VALUE_material} {STEEL}" instead of a material code.

The capability to use multiple namespaces could be done now i believe through a system where one would use something like "{namespace}{mt}" to indicate all unqualified attributes are from the "mt" namespace--no registration needed EXCEPT all hard-wired BRL-CAD attributes would have to have something like "std:" as a prefix. e.g., "std:region" or "std:material_t". Then the default namespace would be "{namespace}{std}", even if not explicitly shown on _GLOBAL.

On a voluntary basis, user namespaces could be registered along with any attributes registrants would like to be to made public. BRL-CAD would incorporate such data into its libraries and provide an API to extract the data for use.

The minimum feature that would need to be done first is to provide a minimal set of registered attributes in the "std" (default) namespace and an API to access them.

Discussion

  • Sean Morrison

    Sean Morrison - 2011-01-13

    Funny you should mention namespaces. The work going into the Geometry Service has resulted in a lot of discussion regarding the need for proper namespace support. It's likely a feature that will be implemented this year, though with considerable changes on the implementation detail.

    I'll see if the current thoughts can get documented up on the wiki so we can discuss in more detail. The basic idea, though, is that .g files would become implicit file-scoped namespaces with the possibility of file namespace overrides.

    So as example, a model.g file would have a model.g implicit namespace or a default namespace set on _GLOBAL. Individual objects become scopeable through naming convention, sph.s in model.g could be referenced as "sph.s" which would imply the default namespace or with an explicit namespace such as "covart::sph.s". Using that, you can then always merge two .g files without naming conflicts with a simple three-way merge selection. Example merging two files: A.g + B.g -> C.g would mean either
    1) C.g gets A:: as default and B:: explicit,
    2) C.g gets B:: default and A:: explicit, or
    C.g retains implicit C:: so both A:: and B:: become explicit.

     
  • Sean Morrison

    Sean Morrison - 2011-01-13
    • milestone: --> Major Effort
    • priority: 5 --> 9
    • status: open --> open-accepted
     
  • Tom Browder

    Tom Browder - 2011-01-13

    Wow, I didn't even think of the namespace as applied to the whole database, but it only make good sense. And the uses for concatenation are legion! Nice--can't wait.

     
  • Tom Browder

    Tom Browder - 2011-01-15

    I would like to register "ManTech" (and alias "mti") for any name space registry that is started for BRL-CAD.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks