When I try to define an attribute named :method, I get the following error:

Attributor::DumpError: Error while dumping attribute method of type V1::MediaTypes::Hello for context $. Reason: wrong number of arguments (0 for 1)

ArgumentError: wrong number of arguments (0 for 1)

This is possibly related to #71

Attributor is severely lacking in terms of documentation. General usage needs to be documented along with special documentation for every built in attributor type. I think it would also be useful to add documentation on how to implement custom types.

1. Support array of regular expressions to use for value validation. Either Attribute could accept a list of regular expressions here, or we could provide some way for the type to override the type to override that behavior (so at least String can take an array of regexes).
2. Validate that :values are valid
3. Validate that :default is valid
4. And make the part of check_option below less weird.

Weird part:

unless self.type.valid_type?(definition) || definition.is_a?(::Regexp) || definition.is_a?(::String) || definition.is_a?(::Array)
  raise AttributorException.new("Invalid example type (got: #{definition.class.name}). It must always match the type of the attribute (except if passing Regex that is allowed for some types)")
end

This is because Ruby strips off the :: before evaluating a constant.

We have this pattern repeated in a number of places: if type.respond_to?(:attributes) || type.respond_to?(:member_attribute) and could simplify it if we had an easy way to tell if a type was a "complex" one or represented a single value.

There doesn't seem to be a way to set a description on a attributor model. This seem like a very useful thing to have. Hash and Collection could support it as well for some uses.

https://github.com/rightscale/attributor/pull/2#discussion_r6580310

Collection and Struct especially need to be tightened up.

Attributor::Model definition tends to look heavy. It would be nice to have a default type and default options for its attributes when you define a model.
How it is:

    class Definition < Attributor::Model
      attributes do
        attribute :action, String, required: true
        attribute :project_id, String, required: true
        attribute :resource_type, String, required: true
        attribute :service, String, required: true
        attribute :service_id, String, required: true
        attribute :status, String, required: true
        attribute :task_id, String, required: true
        attribute :vendor, String, required: true
        attribute :tracking_number, String
        attribute :output, Hash
      end
    end

How it could look like:

    class Definition < Attributor::Model
      attributes(String, required:true) do
        attribute :action
        attribute :project_id
        attribute :resource_type
        attribute :service
        attribute :service_id
        attribute :status
        attribute :task_id
        attribute :vendor
        attribute :tracking_number, required: false
        attribute :output, Hash, required: false
      end
    end
end

where "String" is a default attribute type and default value for "required" is "true".

Two related issues:

• ignore unspecified values
• capture unspecified values into a "splat" type attribute/key.

Per discussion here: https://github.com/rightscale/attributor/pull/2#discussion_r6558094

Currently, dumping a Regexp object as JSON produces a not very human friendly string:

Regexp.new(/yoyo/).to_s
"(?-mix:yoyo)"

We might need to use our own Regexp classes for these options, that can more easily display themselves as strings.
Note: We might want to use Mustermann for that too, something to explore.

Currently, the Attributor::Hash returned when loading an attribute of type Attributor::Hash doesn't quack like a Ruby Hash.

[2] pry(main)> config.has_key?('foobar')
NoMethodError: undefined method `has_key?' for #<Attributor::Hash:0x007fb6e008cd90>
from (pry):2:in `block (2 levels) in <top (required)>

We should fix this.

It's important to know what failed to parse in JSON. However, including that information in the exception message might be too long (for large JSON). Might be better to log this information.

Also, may be important to consider not logging sensitive data, such as SSH keys material.

Per discussion here: https://github.com/rightscale/attributor/pull/26/files#r6810501

https://github.com/rightscale/attributor/pull/2#discussion_r6585387

We have Struct but it requires specific attributes to be defined. I have a use case for passing a hash through to another API without validating the contents of the hash. I only want to validate 'is-a-hash'.

Comments must follow YARD specification.

Code Comment Standard

This is a copy of an existing feature request in Praxis (praxis/praxis#98), which should really an attributor feature request.

This is because there is no Boolean type defined in Ruby, thus syntax parsing fails with:

/Users/justingaylor/Work/attributor/spec/attributor_spec.rb:18:in `block (3 levels) in <top (required)>': uninitialized constant Boolean (NameError)
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:246:in `module_eval'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:246:in `subclass'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:232:in `describe'
    from /Users/justingaylor/Work/attributor/spec/attributor_spec.rb:6:in `block (2 levels) in <top (required)>'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:246:in `module_eval'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:246:in `subclass'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:232:in `describe'
    from /Users/justingaylor/Work/attributor/spec/attributor_spec.rb:5:in `block in <top (required)>'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:246:in `module_eval'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:246:in `subclass'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/example_group.rb:232:in `describe'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/dsl.rb:18:in `describe'
    from /Users/justingaylor/Work/attributor/spec/attributor_spec.rb:4:in `<top (required)>'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/configuration.rb:896:in `load'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/configuration.rb:896:in `block in load_spec_files'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/configuration.rb:896:in `each'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/configuration.rb:896:in `load_spec_files'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/command_line.rb:22:in `run'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/runner.rb:80:in `run'
    from /Users/justingaylor/.rightscale_bundle/attributor/ruby/1.9.1/gems/rspec-core-2.14.5/lib/rspec/core/runner.rb:17:in `block in autorun'

Per discussion here: https://github.com/rightscale/attributor/pull/26/files#r6809527

Trying to construct the below attribute definition should raise an exception.

attribute_definition = Proc.new do
  Proc.new do
    attribute 'months', Attributor::Integer
  end
end

klass = Attributor::Struct.construct(attribute_definition)

It should not have words like 'suicidal' and 'infected' when we make public docs.

https://github.com/rightscale/attributor/pull/2#discussion_r6589059

IMO, it would be nice to have attributor use a version of randexp that uses a modified dictionary file bundled with attributor with suitable words (and possibly allowing the host app to specify its own dictionary file for convenience).

Per discussion here: https://github.com/rightscale/attributor/pull/16/files#r6722390

It should be possible to make TrueClass and FalseClass both have a common ancestor and implement Attributor::Boolean.native_type, provided that the following points are observed:

• The parent class of TrueClass and FalseClass needs to be in the Attributor namespace somewhere.
• We cannot mix anything into the classes other than logic to report that TrueClass and FalseClass are Attributor::Boolean objects.
• Also confirm that === works.

For Inspiration:
https://github.com/mongoid/mongoid/blob/master/lib/mongoid/extensions/boolean.rb
https://github.com/mongoid/mongoid/blob/master/lib/mongoid/extensions/false_class.rb
https://github.com/mongoid/mongoid/blob/master/lib/mongoid/extensions/true_class.rb

It's important to know what failed to parse in JSON. However, including that information in the exception message might be too long (for large JSON). Might be better to log this information.

Also, may be important to consider not logging sensitive data, such as SSH keys material.

Per discussion here: https://github.com/rightscale/attributor/pull/26/files#r6810501

If an attribute is created like so:

attribute 'state', String, :values => ['operational', 'terminated']

Then the random generation for String give a value which is not one of the required :values.

To fix this, we need to make String.example perform an Array#sample on the array of values when values is set.

Trying to generate examples for:

• a simple Attributor::Collection (without the .of(...) )
• an Attributor::Hash with keys defined in the block

fails with something like:

 TypeError: no implicit conversion of Array into String
         # ./lib/attributor/types/hash.rb:127:in `+'
         # ./lib/attributor/types/hash.rb:127:in `block in example'
         # ./lib/attributor/types/hash.rb:126:in `each'
         # ./lib/attributor/types/hash.rb:126:in `example'

Right now, an error when loading an attribute can only report the problem, but cannot say what the name of the attribute it happened on.

Need to percolate the context down on loading, so that this can be properly done.

Need to be careful about performance passing and concatenating strings...perhaps we can pass arrays with the name hierarchy, and only concatenate whenever it is needed

Note: is this worth to port to validation (i.e. passing the context as arrays instead of hashes?)

It's about time we did. It's getting a bit muddled in Skeletor MediaTypes to have mixed symbols and strings.

When providing an example in an attribute fails, unless it it a String (or an Array, Regexp or a Proc)

For example, this definition:

attribute :version, Integer, example: 13

will end up giving an error like:

Reason: unknown example attribute type, got: 13

I believe the issue is that the example function was never updated to work on things other than strings here: https://github.com/rightscale/attributor/blob/master/lib/attributor/attribute.rb#L138

I believe the fix is to simply remove that String case, and put it at the end, to return the unmodified val for any other type that is not special (Regexp, Proc, Array)

In the example below attribute ":attributes" overlaps with pre existing method "attributes" defined in Attributor::Model.

  class Data < Attributor::Model
    attributes do
      attribute :foo, String
      attribute :attributes, Hash
    end
  end

This compiles and runs. And you do not see any obvious issues until you try to load and validate your attributor model instance where it fails with a weird error:

Attributor::Hash can not validate object of type Hash for $.attributes 

It would be nice to fail earlier (ideally in the model definition) or at least to have a better error message.

Attributor::CSV examples look like regular Attributor::Collection examples. The CSV type should have its own example method so it looks like CSV.

As a user, I should be able to define headers with hyphens in the name like "Content-Type", "X-Api-Version", etc.

But attributor throws a Syntax Error if I try to define a header with hyphens.

headers do
  header :'X-Api-Version', String, values: ['1.0'], required: true
end

SyntaxError: .../ruby/2.1.2/lib/ruby/gems/2.1.0/gems/attributor-2.1.0/lib/attributor/types/model.rb:38: syntax error, unexpected '-', expecting ';' or '\n'
        def X-API-VERSION

The attributor should be able to catch such exceptions.

For ex:

Attributor::Integer.new "percentage", :min=>0, :max=>100

Per discussion here: https://github.com/rightscale/attributor/pull/26/files#r6810418

Also handle element validation on the fix for this issue: https://github.com/rightscale/attributor/pull/26/files#r6810524

When rendering types with subattributes, we need to decide whether subattributes that are nil should be returned or not.

We currently return them:

{
  "timestamps": {
    "created_at": "2014-11-20T20:41:12+00:00",
    "updated_at": "2014-11-20T20:43:22+00:00",
    "deleted_at": null
  }
}

Only attribute options that apply uniformly to all types (e.g. :regexp, :required, :required_if) should be validated in the Attributor::Type module. The rest of options (e.g. :min, :max, :max_length, :empty?, etc.) have validation that depends on the specific type and may not be meaningful for other types.

1. Decide if we should or shouldn't
2. Implement handling
3. Add specs

For example:

$ bundle exec irb
irb(main):001:0> require 'attributor'
=> true
irb(main):002:0> Attributor::String.load([1,2,3])
=> "[1, 2, 3]"

Underneath, I see that the Attributor::String type does String(value), but in this case, it doesn't seem intuitive what should be done when a complex type like an Array or Hash are passed in.

In my particular case, a YAML file was incorrectly specifying a String value as an Array, then when trying to load it we were suddenly getting array brackets around the expected string. It would have been preferable in this case to receive an Attributor error saying that Array in not a valid String.

https://github.com/rightscale/attributor/pull/2#discussion_r6559894

If an attribute is an optional collection and nil is given, the render code blows up later on with:

NoMethodError - undefined method collect' for nil:NilClass#012/usr/lib/ruby/gems/2.1.0/bundler/gems/attributor-14efe92c3ac7/lib/attributor/types/collection.rb:95`

Either Collection.dump or Collection.load need to handle nil values. Probably the latter.

Attributor has a few huge pain points in its exception handling. The biggest offender probably being Attribute#load, who loves to eat errors that come from lazy attribute creation and have nothing to do with the actual loading at hand.

I can think of at least two fixes (both should be done):

1. add a separate hierarchy of exceptions that specifically does not derive from StandardError for those exceptions that are fatal and a result of a misconfiguration.
2. rework the myriad Type.load to not rely on exceptions like this one for reporting malformed data: ArgumentError: invalid value for Integer(): "hi"

Per discussion here: https://github.com/rightscale/attributor/pull/2#discussion_r6557670

Somewhere in the rendering process, it's barfing on a symbol value for an String attribute.

Missing types Date & Decimal

Should be more or less similar to how we validate Integer.example:

https://github.com/rightscale/attributor/pull/19/files

See below PR comment for more info:
https://github.com/rightscale/attributor/pull/16#discussion_r6722782

We should give specific Attributor exceptions for all our error cases.

A String attribute with a regexp option defined as /\w+(,\w+)*/ breaks example generation.

Attributor::String.example(options:{regexp: regex})
# => RuntimeError: 
  Sorry, "(...)*" is too vague, try setting a range: "(...){0, 3}"

The issue is that 3rd-party DSLs such as Rake (pre-v10) will define methods on Object that can conflict with attribute names. Since Model does not remove pre-existing method definitions it will simply inherit from Object a method such as 'namespace'. When the 'namespace' attribute is invoked the code instead calls through to Rake v9.

Using BasicObject is tricky, of course, because it lacks useful methods like #to_s, #inspect, #methods, etc