Move Swagger types and warnings under /generator namespace

[PanosCodes]

Why

I'm woking on PR to make generators pluggable and allow external generators to be used by apipie.
This PR is a first step to start moving the Swagger 2.0 generator under /generator namespace.

How

It introduces

• Apipie::Generator::Swagger::TypeExtractor that is responsible to convert an Apipie::Validator to a Swagger type
• Apipie::Generator::Swagger::Warning & Apipie::Generator::Swagger::WarningWriter to handle conditional logic on when a warning should be logged or not.

It's just a refactor and does not add any new functionality for the end user and it should not introduce any breaking changes.

[mathieujobin]

I prefer preventing wide indent by adding a return after the assignation.
can you update to

expected_type = 
  if string?
    :string
  elsif boolean?
    :boolean
  elsif enum?
    :enum
  else
    @validator.expected_type.to_sym
  end

[PanosCodes]

That's fine with me. 036e748

Should we add it as a Rubocop cop ?

[mathieujobin]

This is a really cool refactor, I need more time to review, but I intend to merge...

[mathieujobin]

now that I am reading this properly.. maybe this was the original code... but I wonder why the if/elsif/elsif/else when @validator.expected_type.to_sym probably already return the right value for string, boolean, and enum ?

[PanosCodes]

What was confusing to me as well.
There are a couple of issues we handle here

ParamDescription's validator can be

• nil
• Apipie::Validator::BaseValidator
• ResponseDescriptionAdapter::PropDesc::Validator

Updated Yard comment dc88775

---

In case of nil we want to default to string

---

Apipie::Validator::EnumValidator#expected_type returns string

---

ResponseDescriptionAdapter::PropDesc::Validator#expected_type can we whatever by if we give it values that are [true, false] we need to result into boolean.