apiaryio / drafter

API Blueprint Parser (C++)
https://apiblueprint.org/
MIT License
301 stars 54 forks source link

MSON - array|enum samples wrong parsed #614

Open abtris opened 9 years ago

abtris commented 9 years ago

@klokane opened apiaryio/snowcrash#327

according to MSON spec: https://github.com/apiaryio/mson/blob/master/MSON%20Specification.md#44-sample

- list: 3, 4 (enum, sample)

Is equivalent to:

- list: *3, 4* (enum)

but if you sent it to snowcrash, following blueprint:

# <API name>
<API description>

# Data Structures

## User (object)
- list1: 3, 4 (enum, sample)
- list2: *3, 4* (enum)

Result is following:

_version: "3.0"
metadata: []
name: "<API name>"
description: "<API description>\n\n"
element: "category"
resourceGroups: []
content:
  -
    element: "category"
    content:
      -
        element: "dataStructure"
        name:
          literal: "User"
          variable: false
        typeDefinition:
          typeSpecification:
            name: "object"
            nestedTypes: []
          attributes: []
        sections:
          -
            class: "memberType"
            content:
              -
                content:
                  name:
                    literal: "list1"
                  description: ""
                  valueDefinition:
                    values:
                      -
                        literal: "3"
                        variable: false
                      -
                        literal: "4"
                        variable: false
                    typeDefinition:
                      typeSpecification:
                        name: "enum"
                        nestedTypes: []
                      attributes:
                        - "sample"
                  sections: []
                class: "property"
              -
               content:
                  name:
                    literal: "list2"
                  description: ""
                  valueDefinition:
                    values:
                      -
                        literal: "*3"
                        variable: false
                      -
                        literal: "4*"
                        variable: false
                    typeDefinition:
                      typeSpecification:
                        name: "enum"
                        nestedTypes: []
                      attributes: []
                  sections: []
                class: "property"

list1 has sample atribute, list2 has no. And valueDefinition are in both cases different too

abtris commented 9 years ago

@klokane commented

ping @pksunkara @zdne please take a look

same result for array

abtris commented 9 years ago

@pksunkara commented

As I said, this is intentional. The AST produced by snowcrash should depict what the user exactly wrote. Even though, they mean the same, they can be represented differently in the AST.

Although, there is a different bug in this too. https://github.com/apiaryio/snowcrash/issues/286

abtris commented 9 years ago

@klokane commented

Oh sry for duplicity, issue apiaryio/snowcrash#286 I miss. I'm in trouble in refract AST implementation because there is no way to say if value is sample. Except workarround, while I check last && first value for presence of asterisk, and cut them from literal. But I mean it is really weird solution!

What do you mean about it @zdne ?

abtris commented 9 years ago

@zdne commented

@klokane @pksunkara

The AST produced by snowcrash should depict what the user exactly wrote

Originally this was the case, yes. However as we are moving forward this should not be the case in a future. I would strongly recommend to move away from different AST for different notations of the same thing (as is the case here). Instead – in a future – both should be parsed into the same structure (refract tree). It is the task for a (future) source map to help user – if needed – to figure out whether the sample value comes from one line or multiple lines.

So I do not think this is a bug at the moment, however when we move to parsing into refract I would move away fro this practice (it will also make manipulation with the parse (refract) tree a lot easier).

abtris commented 9 years ago

@zdne commented

@klokane as for any issues with refract implementation – can we discuss it over Slack or in person?

abtris commented 9 years ago

@klokane commented

@zdne i mean, better will be personal with public output opened for comments