Overview

At present when the parser fails we give the user no idea as to why it failed; we just return the failed state. In theory we should be reporting errors:

        on_error<fail>
            (
                type_name,
                std::cout << val("Error! Expecting ")
                << _4                             // what failed?
                << val(" here: \"")
                << construct<std::string>(_3, _2) // iterators to error-pos, end
                << val("\"")
                << std::endl
                );

In practice this never does anything.

Requirements

• get the on_error expression to trigger when an error occurs
• raise an exception with the contents that we are sending to std::cout at present.

At present its not possible to declare an attribute of type std::function anywhere in a diagram. It won’t really be possible to do so for entities and values because boost serialisation will always be a problem. Having said that we should make sure the parser is able to parse these expressions and worry about serialisation separately.

Examples:

std::function<void(int)> 
std::function<void()>
std::function<void(const Foo&, int)> 

This story was originally backlogged here [1].

Links:

[1] https://github.com/DomainDrivenConsulting/dogen/blob/master/doc/agile/product_backlog.org#add-support-for-stdfunction

We need to handle properly the following cases:

• totally blank name.
• template with angle brackets but nothing inside: a<>.
• template with angle brackets, type and then a comma: a<b,>.

This story was originally backlogged here [1]

Links:

https://github.com/DomainDrivenConsulting/dogen/blob/master/doc/agile/product_backlog.org#add-tests-to-identifier-parser-with-invalid-names

[1]

Overview

At present Dogen uses a very simple boost spirit-based parser to parse type names[1]. The parser was designed for simple expressions such as:

some_namespace::my_type<other_type<a::b>>

The output of the parser is what we call a name_tree, which represents the names in a tree-like structure:

some_namespace::my_type
   |
   --- other_type
        |
        ---- a::b

This tree-like structure is then sent to the resolver for name resolution. However, we soon hit a problem: some names are allowed to have spaces, but most do not. For example "unsigned int" is a valid name, but "my type" is not. We solved this problem by hard-coding all of the built-ins into the parser itself so that only those that matched were deemed valid, but any other name with spaces would break. Trouble was, when we did this, a small number of use cases failed; whilst integer is correctly parsed as integer, longer is parsed as long with some extra characters. This is due to the hackery we did around support unsigned long long.

This meant it was not possible to have attributes such as long_primitive (in the primitives test model). With @sehesnips quick fix[2] this was resolved, but he mentioned[3] a number of other valid concerns:

This strictly just makes the tests pass. It does not address other lingering issues in the parser yet, nor
does it add testcases for more complicated uses (what about parsing long␣␣long or unsigned␣␣␣char?).

Requirements

The fundamental objectives here are:

• is to allow the valid use of spaces for built-ins and only on languages that have them such as C++;
• to disallow them for user types or on other languages such as C#.

The parser does not need to do anything else since the resolver will catch non-existing types. Thus we can:

• remove from the parser all of the types which do not have spaces (bool, wchar_t, etc) solving this issue [4].

However we should also cater for cases where there are more than one space.

The complete list is then:

This story was originally captured in the backlog here [5].

Links:

[1] https://github.com/DomainDrivenConsulting/dogen/blob/master/projects/yarn/src/types/name_tree_parser.cpp
[2] 566743c
[3] https://sourceforge.net/p/spirit/mailman/spirit-general/?viewmonth=201702
[4] https://github.com/DomainDrivenConsulting/dogen/blob/master/doc/agile/product_backlog.org#identifier-parser-has-hard-coded-built-ins
[5] https://github.com/DomainDrivenConsulting/dogen/blob/master/doc/agile/product_backlog.org#partial-matching-of-built-ins-doesnt-work-for-certain-types

At present our parser does not support arrays such as:

int[50];

This should result on a name with a size associated with it. The parser cannot cope with this. Ideally one should be able to declare a const for the size on the class too:

            static const int maxLimit = 50;
            int objects[maxLimit];

So that we'd just recall the size parameter as a string in the name tree rather than just expect it to be an integer.

At present its not possible to create a type that has a reference to another type:

std::map<std::string, std::string>&

The main reason is that our parser is not clever enough to read & or *. This should be a case of updating the parser to cope with references and then adding reference to property or nested type name. This ticket is only concerned with the parser side.

In addition we also do not support const:

boost::shared_ptr<const my_type>

The original ticket in the backlog is available here [1].

Links:

[1] https://github.com/DomainDrivenConsulting/dogen/blob/master/doc/agile/product_backlog.org#add-support-for-references-and-pointers-to-types