How to handle a nested dictionary with mixed key/values?

Question

I would like to create a dictionary variable for a vimL script. That dictionary will hold information related to a folder structure. However, I have a bit of hard time designing this variable and also I came across some difficulties while handling the information stored in that variable. Below is an example dictionary variable.

let g:myTree = { 
        \ 'base' : {
            \ 'path' : '__base',
            \ 'main' : {'path' : '__base/__main'},
            \ 'config' : {
                \ 'path' : '__base/__/config',
                \ 'modules' : {'path' : '__base/__config/__modules'},
                \ 'settings': {
                    \ 'path' : '__base/__config/__settings',
                    \ 'gui' : {
                        \ 'path' : '__base/__config/__settings/__gui',
                        \ 'linux' : {'path' : '__base/__config/__settings/__gui/__linux'},
                        \ },
                    \ },
                \ },
            \ },
        \ }

The idea was to be able to access the data bits with the . notation. For example g:myTree.base should return __base. However, I have noticed that I need an additional key path in order to be able to package the nested information, so the access is done through g:myTree.base.path for __base.

The first questions would be:

Is there a way to avoid the use of path and directly access the data in the following format:

g:myTree.base for __base

g:myTree.base.main for __base/__main

g:myTree.base.config.modules for __base/__config/__modules

g:myTree.base.config.settings.gui.linux for __base/__config/__settings/__gui/__linux

The second question would be:

How do we iterate and access (or modify) the data bits stored in the path key throughout the whole depth of the dictionary. I have encountered a problem due to the fact that the path key stores a string value but the next key would be storing a dictionary value. This creates a variable mismatch when iterating through the dictionary. What would be the solution to this?

Thanks.

Answer 1

I don't think you can set a key as the "default" for a dictionary. You should probably look into the other supported scripting languages, like Python or Ruby.

As for the second problem, you can check the type:

function! RecurseForPath(dict)
    for key in keys(a:dict)
        if key == 'path'
            echo a:dict[key]
        elseif type(a:dict[key]) == type({})
            call RecurseForPath(a:dict[key])
        endif
    endfor
endfunction

call RecurseForPath(myTree)

From :h type:

type({expr})    The result is a Number, depending on the type of {expr}:
                        Number:     0
                        String:     1
                        Funcref:    2
                        List:       3
                        Dictionary: 4
                        Float:      5
                        Boolean:    6 (v:false and v:true)
                        None        7 (v:null and v:none)
                        Job         8
                        Channel     9
                To avoid the magic numbers it should be used this way: 
                        :if type(myvar) == type(0)
                        :if type(myvar) == type("")
                        :if type(myvar) == type(function("tr"))
                        :if type(myvar) == type([])
                        :if type(myvar) == type({})
                        :if type(myvar) == type(0.0)
                        :if type(myvar) == type(v:false)
                        :if type(myvar) == type(v:none)

The output, with the variable from the question, is:

__base
__base/__main
__base/__/config
__base/__config/__modules
__base/__config/__settings/__gui/__linux
__base/__config/__settings/__gui
__base/__config/__settings

Answer 2

The idea was to be able to access the data bits with the . notation. For example g:myTree.base should return __base. However, I have noticed that I need an additional key path in order to be able to package the nested information, so the access is done through g:myTree.base.path for __base.

This is not really how dictionaries (or hashes, or tables, or whatever your preferred term is) work in any language as far as I know. In fact, I can't see how it could conceivably work.

How would you disambiguate between calling g:myTree.base when you really want to get this dict, and g:myTree.base when you want g:myTree.base.__base? There is no real way to to that.

Even in more advanced languages with operator overloading, such as Python or Ruby, it would actually be a challenge to implement this; in Python we could override the __getitem()__ method, but that doesn't get called when we merely reference a dict. I would be surprised if anyone would be able to come up with a working implementation of this to be honest.

What you can do is assign functions to dictionaries to return the values you want; this is sort of like "poor man's object oriented programming".

I'm not entirely sure what your task is or what you're trying to do, so I'm not sure if this is the "right tool for the right job", but it could very well be.

A simple example might look like:

fun! s:full_path() dict
    return self.base . self.path
endfun

let g:my_tree = {
    \ 'base': '/home/martin/',
    \ 'path': '.vim',
    \ 'full_path': function("s:full_path"),
\}

And when calling :echo g:my_tree.full_path() you will get /home/martin/.vim. See :help Dictionary-function and :help Funcref for the full documentation.

You could emulate part of the behaviour described in your answer; but I'm not sure if that would be a sane thing to do.

Above all, remember Eric S. Raymond's "Rule of Representation" from The Art of Unix Programming (it's free!):

Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.

Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic. See Rob Pike's Rule 5.

Data is more tractable than program logic. It follows that where you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data.

The Unix community did not originate this insight, but a lot of Unix code displays its influence. The C language's facility at manipulating pointers, in particular, has encouraged the use of dynamically-modified reference structures at all levels of coding from the kernel upward. Simple pointer chases in such structures frequently do duties that implementations in other languages would instead have to embody in more elaborate procedures.

---

As for the second part of your question, I believe muru already did a good job of answering that, so I'll not repeat it here ;-)